Hi,
> If you have access to x86_64-linux, you can easily test it yourself with:
> make -C gcc check-gcc RUNTESTFLAGS='--target_board=unix\{-m64,-m32/-
> march=i386\} dg.exp=pr61441.c'
>
> Your patch does help.
Thanks, I tested the changes and it worked fine.
> issignalling is a GNU extension o
On Thu, Jan 07, 2016 at 06:48:25AM +, Saraswati, Sujoy (OSTL) wrote:
> Hi,
>
> > On Thu, Nov 26, 2015 at 08:38:55AM +, Saraswati, Sujoy (OSTL) wrote:
> > > PR tree-optimization/61441
> > > * gcc.dg/pr61441.c: New testcase.
> >
> > Note the testcase fails on i686-li
Hi,
> On Thu, Nov 26, 2015 at 08:38:55AM +, Saraswati, Sujoy (OSTL) wrote:
> > PR tree-optimization/61441
> > * gcc.dg/pr61441.c: New testcase.
>
> Note the testcase fails on i686-linux, and even -fexcess-precision=standard
> doesn't help (-ffloat-store works, but that
On Thu, Nov 26, 2015 at 08:38:55AM +, Saraswati, Sujoy (OSTL) wrote:
> PR tree-optimization/61441
> * gcc.dg/pr61441.c: New testcase.
Note the testcase fails on i686-linux, and even -fexcess-precision=standard
doesn't help (-ffloat-store works, but that is a big hammer
Hi,
> If you haven't set up write-access to the repository, please go ahead and get
> that process started:
>
> https://www.gnu.org/software/gcc/svnwrite.html
>
> You can list me as your sponsor on the form.
>
> Once your account is set up, you can commit patches which have been
> approved.
>
On 12/02/2015 12:08 PM, Joseph Myers wrote:
On Wed, 2 Dec 2015, Jeff Law wrote:
Why let NEGATE_EXPR and ABS_EXPR pass through here? I realize that these can
often be implemented with bit-twiddling, so they're usually considered
special. BUt in this case aren't we just dealing with constants a
On Wed, 2 Dec 2015, Jeff Law wrote:
> Why let NEGATE_EXPR and ABS_EXPR pass through here? I realize that these can
> often be implemented with bit-twiddling, so they're usually considered
> special. BUt in this case aren't we just dealing with constants and wouldn't
> we want to still express th
On 11/26/2015 01:38 AM, Saraswati, Sujoy (OSTL) wrote:
Hi,
This patch avoids various transformations with signaling NaN operands when
flag_signaling_nans is on, to avoid folding which would lose exceptions. A test
case for this change is also added as part of this patch.
Regards,
Sujoy
20
On 11/26/2015 01:27 AM, Saraswati, Sujoy (OSTL) wrote:
Hi,
This series of patches fixes PR61441. The fix is broken into 5 patches.
The first one adds REAL_VALUE_ISSIGNALING_NAN.
2015-11-26 Sujoy Saraswati
PR tree-optimization/61441
* real.c (real_issignaling_nan): N
On Thu, Nov 26, 2015 at 9:31 AM, Saraswati, Sujoy (OSTL)
wrote:
> Hi,
> This patch removes flag_errno_math check for RINT, treating it similar to
> nearbyint.
> Regards,
> Sujoy
Ok.
Richard.
> 2015-11-26 Sujoy Saraswati
>
> PR tree-optimization/61441
> * match.pd (
Hi,
This patch avoids various transformations with signaling NaN operands when
flag_signaling_nans is on, to avoid folding which would lose exceptions. A test
case for this change is also added as part of this patch.
Regards,
Sujoy
2015-11-26 Sujoy Saraswati
PR tree-optim
Hi,
This patch makes resulting NaN values to be quiet NaN for real value
operations, irrespective of the flag_signaling_nans flag. The caller has the
responsibility to avoid the operation if flag_signaling_nans is on.
Regards,
Sujoy
2015-11-26 Sujoy Saraswati
PR tree-optimiza
Hi,
This patch removes flag_errno_math check for RINT, treating it similar to
nearbyint.
Regards,
Sujoy
2015-11-26 Sujoy Saraswati
PR tree-optimization/61441
* match.pd (f(x) -> x): Removed flag_errno_math check for RINT.
Index: gcc/match.pd
==
This patch uses REAL_VALUE_ISSIGNALING_NAN instead of REAL_VALUE_ISNAN to avoid
the operation for sNaN.
Regards,
Sujoy
2015-11-26 Sujoy Saraswati
PR tree-optimization/61441
* fold-const.c (const_binop): Use REAL_VALUE_ISSIGNALING_NAN instead
of REAL
Hi,
This series of patches fixes PR61441. The fix is broken into 5 patches.
The first one adds REAL_VALUE_ISSIGNALING_NAN.
2015-11-26 Sujoy Saraswati
PR tree-optimization/61441
* real.c (real_issignaling_nan): New.
* real.h (real_issignaling_nan, REAL_VALUE_ISSIGN
Hi,
> I think the general principle is:
>
> * The caller decides whether folding is desirable (whether it would lose
> exceptions, for example).
>
> * The real.c code is called only when the caller has decided that folding is
> desirable, and should always produce the correct output (which for a
On Fri, 6 Nov 2015, Sujoy Saraswati wrote:
> > Shouldn't real_convert do this rather than the caller needing to do it?
>
> Yes, it should be. I had started by doing this within real_convert but
> then saw that there are quite a few callers where I should add the
> check for flag_signaling_nans. T
Hi,
> This is looking pretty close to ready to go in, but the patch also seems
> to be doing several things at once and it might be easier to review if
> split into separate logical pieces. For example (this is an illustration,
> not necessarily saying it should be exactly this way): (1) Add
> RE
On Thu, 5 Nov 2015, Sujoy Saraswati wrote:
> > Some other places in this patch have similar issues with checking
> > HONOR_SNANS && REAL_VALUE_ISNAN when they should check if the particular
> > value is sNaN.
>
> I modified the code to check for sNaN specifically. The modified patch
> is below.
Hi,
> It seems this code has moved to fold-const.c, so the patch will need
> updating.
I have updated the patch and sending again.
> Now, is it actually correct for integer_valued_real_single_p (now) to
> treat sNaN as an integer? Looking at existing uses, they all appear to be
> in match.pd: i
On Tue, 13 Oct 2015, Sujoy Saraswati wrote:
> Index: gcc/builtins.c
> ===
> --- gcc/builtins.c (revision 228700)
> +++ gcc/builtins.c (working copy)
> @@ -7357,7 +7357,11 @@ integer_valued_real_p (tree t)
> && i
This is a ping for the patch to fix 61441.
Regards,
Sujoy
On Tue, Oct 13, 2015 at 4:16 PM, Sujoy Saraswati wrote:
> Hi,
> This is another modified version of the patch, incorporating the
> previous comments.
>
> Bootstrap and regression tests on x86_64-linux-gnu and
> aarch64
Hi,
This is another modified version of the patch, incorporating the
previous comments.
Bootstrap and regression tests on x86_64-linux-gnu and
aarch64-unknown-linux-gnu passed with changes done on trunk.
Is this fine ?
Regards,
Sujoy
2015-10-13 Sujoy Saraswati
PR tree-optimization/6
On Wed, 16 Sep 2015, Sujoy Saraswati wrote:
> > If -fsignaling-nans, then folding of expressions involving sNaNs should be
> > disabled, outside of static initializers - such expressions should not get
> > folded to return an sNaN (it's incorrect to fold sNaN + 1 to sNaN, for
> > example). I thin
Hi,
>> I'll leave the correctness part of the patch to Joseph who knows FP
>> arithmetic better than me,
>> implementation-wise this is ok if you fix the REAL_CST sharing issue.
Ok, will change this.
> Changing fold_abs_const is wrong - abs of sNaN is sNaN, no exceptions
> raised. Changing real
On Mon, 14 Sep 2015, Richard Biener wrote:
> I'll leave the correctness part of the patch to Joseph who knows FP
> arithmetic better than me,
> implementation-wise this is ok if you fix the REAL_CST sharing issue.
Changing fold_abs_const is wrong - abs of sNaN is sNaN, no exceptions
raised. Cha
On Thu, Sep 10, 2015 at 9:30 AM, Sujoy Saraswati wrote:
> Hi,
> Here is a modified patch for this. The change this time is in
> fold-const.c and real.c.
>
> Bootstrap and regression tests on x86_64-linux-gnu and
> aarch64-unknown-linux-gnu passed with changes done on trunk.
>
> Is this fine ?
>
>
Hi,
Here is a modified patch for this. The change this time is in
fold-const.c and real.c.
Bootstrap and regression tests on x86_64-linux-gnu and
aarch64-unknown-linux-gnu passed with changes done on trunk.
Is this fine ?
Regards,
Sujoy
2015-09-10 Sujoy Saraswati
PR tree-optimizatio
> CCP and other passes ultimatively end up using fold-const.c:const_{unop,binop}
> for constant folding so that is where the fix should go to (or to real.c).
> That
> will automatically handle other passes doing similar transforms.
Thanks for the tip. I will modify my fix and post it.
Regards,
On Wed, Sep 2, 2015 at 1:36 PM, Sujoy Saraswati wrote:
> Hi Richard,
>
>> Note that I'm curious what
>> the actual bug is - is it that (double) sNaN creates a sNaN? Then the fix
>> should be elsewhere, in constant folding itself
>> (fold_convert_const_real_from_real
>> or real_convert).
>>
>> If
Hi Richard,
> Note that I'm curious what
> the actual bug is - is it that (double) sNaN creates a sNaN? Then the fix
> should be elsewhere, in constant folding itself
> (fold_convert_const_real_from_real
> or real_convert).
>
> If that isn't the bug you have very many other passes to fix for the
On Tue, Sep 1, 2015 at 12:23 PM, Sujoy Saraswati wrote:
> The following patch fixes 61441. It converts sNaN to qNaN on folding
> when -fno-signaling-nans is used.
>
> Bootstrap and regression tests on x86_64-linux-gnu and
> aarch64-unknown-linux-gnu passed with changes done on trunk.
>
> Is this f
The following patch fixes 61441. It converts sNaN to qNaN on folding
when -fno-signaling-nans is used.
Bootstrap and regression tests on x86_64-linux-gnu and
aarch64-unknown-linux-gnu passed with changes done on trunk.
Is this fix fine ?
Regards,
Sujoy
2015-09-01 Sujoy Saraswati
PR t
33 matches
Mail list logo
