[Bug c/54192] New: -fno-trapping-math by default?

[Bug c/54192] New: -fno-trapping-math by default?

[glisse at gcc dot gnu.org]

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

             Bug #: 54192
           Summary: -fno-trapping-math by default?
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: glisse@gcc.gnu.org


Hello,

I am not sure about the "component" (I am actually more interested in the C++
behavior, but I assume C and C++ will remain the same), or about posting this
to bugzilla instead of the mailing-list.

I would like to know people's opinion about making -fno-trapping-math the
default. One strong argument in favor is that -fno-rounding-math is the
default. The 2 options are quite similar. They both affect "special" use of
maths, they both inhibit a number of optimizations, and they both have bugs
(not trying to offend anyone here, it is already great that the options are as
far as they are).

As someone who needs -frounding-math and for whom -fno-trapping-math is safe
and helps performance, you can see why I'd like to change it ;-)

[Bug c/54192] -fno-trapping-math by default?

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-07 12:50:16 UTC ---
The current reasoning is that the C standard allows the implementation to
say that only round-to-nearest is supported but not that the trapping parts
of IEEE are not honored.  The default should always be standard conformant
behavior.

[Bug c/54192] -fno-trapping-math by default?

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2012-08-07 13:13:46 UTC ---
Don't you need to tell the compiler (with the FENV_ACCESS pragma) that you are
going to look at flags, just like you tell it that you are going to use
non-default rounding modes?

"In general, if the state of FENV_ACCESS is ‘‘off’’, the translator can assume
that default modes are in effect and the flags are not tested."

The compiler would also need to #undef FE_DOWNWARD in fenv.h if it wants to
pretend that it only supports round-to-nearest (there is an "if and only if" in
the standard).

I think I see what you mean: if there is only one rounding-mode, then the
pragma has no effect on rounding so you can pretend that it is on. But then the
same applies to trapping, since the standard explicitly allows for
FE_ALL_EXCEPT==0.

[Bug c/54192] -fno-trapping-math by default?

[gabravier at gmail dot com]

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

Gabriel Ravier <gabravier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gabravier at gmail dot com

--- Comment #5 from Gabriel Ravier <gabravier at gmail dot com> ---
Also of note should be the fact that Clang's current default is
`-fno-trapping-math`.

I'm myself kind of curious about how exactly `-ftrapping-math` is interpreted.
It certainly doesn't seem to remove every single kind of non-trapping
math-based optimization: GCC will remove such statements as `(void)1/x;` even
with `-ftrapping-math`, even though that could fault with `x == 0`, and will
optimize things like `float x = 3412897421;` to not do a conversion even though
that conversion could raise an exception (as 3412897421 cannot be exactly
represented as a float), whereas Clang won't do that kind of optimization and
will keep those operations as-is.

[Bug c/54192] -fno-trapping-math by default?

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Sep 2021, gabravier at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
> 
> Gabriel Ravier <gabravier at gmail dot com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |gabravier at gmail dot com
> 
> --- Comment #5 from Gabriel Ravier <gabravier at gmail dot com> ---
> Also of note should be the fact that Clang's current default is
> `-fno-trapping-math`.
> 
> I'm myself kind of curious about how exactly `-ftrapping-math` is interpreted.
> It certainly doesn't seem to remove every single kind of non-trapping
> math-based optimization: GCC will remove such statements as `(void)1/x;` even
> with `-ftrapping-math`, even though that could fault with `x == 0`, and will
> optimize things like `float x = 3412897421;` to not do a conversion even though
> that conversion could raise an exception (as 3412897421 cannot be exactly
> represented as a float), whereas Clang won't do that kind of optimization and
> will keep those operations as-is.

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.

I suppose that argues for a tighter coupling of -fnon-call-exceptions
and -ftrapping-math and in particular not enabling -ftrapping-math
by default (unless -fnon-call-exceptions is enabled?).

Btw, the issue also repeatedly comes up in the context of -ftrapv.

I guess I'll propose a documentation enhancement where we can then
discuss the best way forward.

Note that options like -ftrapv and -ftrapping-math also make GCC
avoid transforms that may turn expressions that do not trap into
expressions that do.  For both that is re-association which can
lead to intermediate integer overflows and intermediate inexact
exception traps.

[Bug c/54192] -fno-trapping-math by default?

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-09-21
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I suppose that argues for a tighter coupling of -fnon-call-exceptions
> and -ftrapping-math and in particular not enabling -ftrapping-math
> by default (unless -fnon-call-exceptions is enabled?).

Nope, in Ada where -fnon-call-exceptions is the default, -fno-trapping-math is
also the default (at least on native platforms).  If you do not do that, then
you end up with EH edges from every single floating-point operations.

[Bug c/54192] -fno-trapping-math by default?

[joseph at codesourcery dot com]

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.

* Ensuring the code generated allows for possible non-local control flow 
from exception traps raised by floating-point operations (this is the part 
where -fnon-call-exceptions might be relevant).

* Disallowing code transformations that might affect whether an exact 
underflow exception occurs in some code (not observable through exception 
flags, is observable through trap handlers).

* Ensuring floating-point operations that might raise exception flags are 
not removed, or moved past code (asms or function calls) that might read 
or modify the exception flag state (not implemented, modulo Marc Glisse's 
-ffenv-access patches from August 2020)

[Bug c/54192] -fno-trapping-math by default?

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
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.

> * Ensuring the code generated allows for possible non-local control flow 
> from exception traps raised by floating-point operations (this is the part 
> where -fnon-call-exceptions might be relevant).
> 
> * Disallowing code transformations that might affect whether an exact 
> underflow exception occurs in some code (not observable through exception 
> flags, is observable through trap handlers).
> 
> * Ensuring floating-point operations that might raise exception flags are 
> not removed, or moved past code (asms or function calls) that might read 
> or modify the exception flag state (not implemented, modulo Marc Glisse's 
> -ffenv-access patches from August 2020)

And indeed while the above points are inter-mangled it might make sense
to split -ftrapping-math into controls for the individual exception flag
kinds (-ffinite-math-only overlaps here to some extent), or at least
try to document the effects of the flags we have on the behavior of
the exception state.

[Bug c/54192] -fno-trapping-math by default?

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #7)
> > I suppose that argues for a tighter coupling of -fnon-call-exceptions
> > and -ftrapping-math and in particular not enabling -ftrapping-math
> > by default (unless -fnon-call-exceptions is enabled?).
> 
> Nope, in Ada where -fnon-call-exceptions is the default, -fno-trapping-math
> is also the default (at least on native platforms).  If you do not do that,
> then you end up with EH edges from every single floating-point operations.

Note this also argues for splitting -ftrapping-math into the FENV access
part and the part that considers exception state changes causing
observable traps (aka for Fortran -ffpe-trap=...).  Mixing both is quite
bad with -fnon-call-exceptions as you say.

[Bug c/54192] -fno-trapping-math by default?

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Internally we might want to introduce
HONOR_FPE_{DIVBYZERO,INEXACT,INVALID,OVERFLOW,UNDERFLOW} so transforms can
be appropriately annotated.  There might be a difference between preserving
and not introducing new, esp. if trapping on the exceptions is enabled
(there's related -fdelete-dead-exceptions).
HONOR_FPE_ANY might be a good "don't know/care" thing to introduce.