On Wed, 1 Jul 2026, Andrea Pinski wrote:
> So GCC has always defaulted to -ftrapping-math but that has always
> come with many issues. Especially if we go by Joseph's definition of
> the flag (from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805#c4
> and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192):
> ```
> 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)
> ```
>
> The second point is something which GCC tries to do in some cases but
> in many others GCC removes the statements that would/could raise
> exception flags. This is especially true when the statement would be
> DCEd as unused. It also has been in this situation since at least
> 3.4.0 (maybe longer).
>
> So my proposal is turn off trapping-math by default for the C and C++
> front-end and also file a bug report for all of the cases where
> -ftrapping-math is removing the statements that it should not be
> removed.
>
> Note clang/LLVM defaults to -fno-trapping-math and so comparisons
> between GCC and LLVM sometimes will not be totally fair. And yes we
> are getting more and more cases where the exception flags matter; e.g.
> vectorizer. So there huge difference starting to show up in
> performance between -fno-trapping-math and -ftrapping-math now too.
I'm all for flipping the default. But I'd also ask for splitting up
this flag so users have more fine-grained control. Specifically
-ftrapping-math also covers alternate exception handling methods
(than flags, like traps), which makes -ftrapping-math quite
awkward when used in conjunction with -fnon-call-exceptions.
Maybe -ffp-exceptions={none,ieee,ieee-alternate}?
I'll note that IEEE exception flags are useful only when FP
environment access and modification is allowed (aka FENV access),
which we do not implement correctly, thus -ftrapping-math is
only useful to a very limited extent.
One complication of #pragma FENV access is that the restrictions
of placement is too lose as we can properly only support
at most per-function level changes via options. It might be
good to have a TU wide -ffenv-access= option which has a
higher chance of being implemented? Or is it reasonable to
sorry () for #pragma FENV access thats "wrongly" placed?
Or just diagnose such as being ignored?
Similar for the newer #pragma STDC FENV_ROUND and FENV_DEC_ROUND
Richard.
