Message ID | alpine.DEB.2.02.1207191701230.5308@stedding.saclay.inria.fr |
---|---|
State | New |
Headers | show |
Hello, an opinion on this? (I just noticed: I'll update the list in the comment visible at the top of the patch if this gets in). On Thu, 19 Jul 2012, Marc Glisse wrote: > Hello, > > the simple patch below passes the testsuite after a c,c++ bootstrap without > new regressions. Note however that > > #include <math.h> > int f(double a, double b){ > return (!isunordered(a,b))&&(a<b); > } > > is then optimized by ifcombine to "return (a<b);", which seems wrong in the > absence of -fno-trapping-math. I don't know if there are ways to trigger this > latent bug without the patch. > > > > 2012-06-15 Marc Glisse <marc.glisse@inria.fr> > > PR tree-optimization/53805 > * fold-const.c (invert_tree_comparison): Do invert ORDERED_EXPR and > UNORDERED_EXPR for floating point. > > --- fold-const.c (revision 189622) > +++ fold-const.c (working copy) > @@ -2096,13 +2096,14 @@ pedantic_non_lvalue_loc (location_t loc, > It is generally not safe to do this for floating-point comparisons, except > for EQ_EXPR and NE_EXPR, so we return ERROR_MARK in this case. */ > > enum tree_code > invert_tree_comparison (enum tree_code code, bool honor_nans) > { > - if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR) > + if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR > + && code != ORDERED_EXPR && code != UNORDERED_EXPR) > return ERROR_MARK; > > switch (code) > { > case EQ_EXPR: > return NE_EXPR;
On Wed, Aug 1, 2012 at 9:21 PM, Marc Glisse <marc.glisse@inria.fr> wrote: > Hello, > > an opinion on this? > > (I just noticed: I'll update the list in the comment visible at the top of > the patch if this gets in). It looks ok to me but I am no floating-point expert. Can you add a testcase? Ok with that change. Thanks, Richard. > > On Thu, 19 Jul 2012, Marc Glisse wrote: > >> Hello, >> >> the simple patch below passes the testsuite after a c,c++ bootstrap >> without new regressions. Note however that >> >> #include <math.h> >> int f(double a, double b){ >> return (!isunordered(a,b))&&(a<b); >> } >> >> is then optimized by ifcombine to "return (a<b);", which seems wrong in >> the absence of -fno-trapping-math. I don't know if there are ways to trigger >> this latent bug without the patch. >> >> >> >> 2012-06-15 Marc Glisse <marc.glisse@inria.fr> >> >> PR tree-optimization/53805 >> * fold-const.c (invert_tree_comparison): Do invert ORDERED_EXPR and >> UNORDERED_EXPR for floating point. >> >> --- fold-const.c (revision 189622) >> +++ fold-const.c (working copy) >> @@ -2096,13 +2096,14 @@ pedantic_non_lvalue_loc (location_t loc, >> It is generally not safe to do this for floating-point comparisons, >> except >> for EQ_EXPR and NE_EXPR, so we return ERROR_MARK in this case. */ >> >> enum tree_code >> invert_tree_comparison (enum tree_code code, bool honor_nans) >> { >> - if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != >> NE_EXPR) >> + if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != >> NE_EXPR >> + && code != ORDERED_EXPR && code != UNORDERED_EXPR) >> return ERROR_MARK; >> >> switch (code) >> { >> case EQ_EXPR: >> return NE_EXPR; > > > -- > Marc Glisse
--- fold-const.c (revision 189622) +++ fold-const.c (working copy) @@ -2096,13 +2096,14 @@ pedantic_non_lvalue_loc (location_t loc, It is generally not safe to do this for floating-point comparisons, except for EQ_EXPR and NE_EXPR, so we return ERROR_MARK in this case. */ enum tree_code invert_tree_comparison (enum tree_code code, bool honor_nans) { - if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR) + if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR + && code != ORDERED_EXPR && code != UNORDERED_EXPR) return ERROR_MARK; switch (code) { case EQ_EXPR: return NE_EXPR;