https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot
com> ---
On Mon, 24 Jun 2019, rguenth at gcc dot gnu.org wrote:
> so I guess it differs from -frounding-math also in a way that it doesn't
> guard FENV access of the exception state (I'd say that is not implemented
> at all, not even in the -frounding-math way) but it guards whether
> the FENV state is set to trap? So its default should match the
> execution environments default?
flag_trapping_math is about disallowing local transformations that would
add or remove the raising of exception flags. It's nothing to do with
traps, except insofar as some systems may permit exceptions to result in a
trap rather than just the raising of a flag. In particular, F.9#3 should
be considered to apply regarding permitted transformations. ("This
specification does not require support for trap handlers that maintain
information about the order or count of floating-point exceptions.
Therefore, between function calls, floating-point exceptions need not be
precise: the actual order and number of occurrences of floating-point
exceptions (> 1) may vary from what the source code expresses.")
Logically, there should be a separate option that is a stronger version of
-ftrapping-math that also prevents global transformations that change
whether an exception flag is raised between two points where it might be
observed (e.g. any non-const function call might examine floating-point
state unless the called function can be seen not to do so, and if non-pure
might also change that state). This would affect code movement and dead
code elimination, for example, and would be needed to fully implement the
exceptions parts of FENV_ACCESS.
If there were anything supporting trap handlers that determine exactly
when an exception occurred, as opposed to the standard C model where you
can test the exception flag bits by calling appropriate fenv.h functions,
I think that should be yet another option.
It is true that if the execution environment does not support
floating-point exceptions (flag bits or traps) at all then there are
various such transformations GCC could apply unconditionally. (But people
don't tend to be concerned that much with optimizing floating-point
performance for soft-float systems, and systems without floating-point
exceptions are typically soft-float.)
