https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192

Drea Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #13 from Drea Pinski <pinskia at gcc dot gnu.org> ---
(In reply to [email protected] from comment #9)
> On Tue, 21 Sep 2021, joseph at codesourcery dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
> > 
> > --- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery 
> > dot com> ---
> > On Tue, 21 Sep 2021, rguenther at suse dot de via Gcc-bugs wrote:
> > 
> > > Yes, as said in other contexts GCC happily _removes_ traps if trapping
> > > is the only side-effect.  _Unless_ you also have -fnon-call-exceptions
> > > enabled which is the only way to observe traps.  So we consider
> > > a trap invoking undefined behavior unless you make them well-defined
> > > via -fnon-call-exceptions.
> > 
> > That might be relevant to traps in the sense of changing control flow when 
> > a floating-point exception is signaled.  -fnon-call-exceptions doesn't 
> > seem very relevant to the -ftrapping-math effects on transformations that 
> > might affect the set of floating-point exception flags raised by some 
> > code.  As per my previous comment, -ftrapping-math currently affects (or 
> > might affect if fully implemented) several different things:
> > 
> > * Disallowing code transformations that cause some code to raise more 
> > exception flags than it would have before.
> > 
> > * Disallowing code transformations that cause some code to raise fewer 
> > exception flags than it would have before.
> 
> I might add that this particular point isn't followed thoroughly.

yes a good example is PR 53805:
```
int f(double a,double b){
  if(a>b) if(a<b) return 1;
  return 0;
}
```

Which since GCC 13 gets optimized (again) to return 0 at -O2. Because evrp
figures out that `a<b` will be zero and then cleanup cfg comes along and
removes the `a>b` comparison too.

So Maybe it is time to declare -fno-trapping-math as the default and go through
the testsuite and add -ftrapping-math as needed for the testcases that are
testing the bits.

Reply via email to