Re: FP fetch_add and "ignoring FP environment" attribute

On Thu, 16 Jul 2026, Matthew Malcomson wrote:

> 1) -fno-trapping-math says that invalid operations do not generate
>    runtime exceptions. This is necessary, but says nothing about
>    allowing us to skip setting status flags in the FP environment.
>    - Hence doesn't seem to give us everything we need.

I think -fno-trapping-math is misnamed - it's about exception flags just 
as much as it's about traps.

> 2) -fno-rounding-math allows optimisations that assume round-to-nearest.
>    This seems to not be sufficient for the fetch_add semantics.
>    libstdc++ FP atomics semantics say can act as if in different FP
>    environment, which I would expect means a hardware implementation can
>    choose whatever FP rounding mode (doesn't have to be the default
>    one).

Indeed, -fno-rounding-math isn't supposed to allow random other rounding 
modes, just round-to-nearest.

> 3) No -ffast-math flag mentions anything about what NaN is generated --
>    These methods need to allow choosing something different, and the
>    AArch64 implementation actually does change what kind of NaN's are
>    produced.

The only property of the NaN produced that's ever significant is whether 
it's a quiet or signaling NaN; at the language level, nothing is defined 
about the sign or payload of a NaN.

Given -fsignaling-nans (not the default), code should produce quiet or 
signaling NaNs according to language semantics.

By default, without -fsignaling-nans, code with only quiet NaN inputs 
should only produce quiet NaN outputs, but operations with a signaling NaN 
input might sometimes return that NaN (or its negation or a version with 
different payload) when the proper semantics would return a quiet NaN, 
because optimizations are applied (such as 1.0 * x -> x) that aren't valid 
for signaling NaNs.

-- 
Joseph S. Myers
[email protected]