Re: FP fetch_add and "ignoring FP environment" attribute

Ah, thanks!

So to make sure I understand correctly, this means:
1) My concern about `-fno-trapping-math` is not a problem.
    (Will need to update the documentation but can use this).
2) `-fno-rounding-math` is indeed not enough for these new methods.
3) The default behaviour is enough to not worry about NaN semantics.

and hence the extra fast-math flag that we'd need is *only* something 
like `-funpecified-rounding` allowing any rounding that the 
implementation chooses.

Would it be reasonable to put a new flag like this into the 
`-ffast-math` flags?  Considering that it's an even more relaxed version 
of `-fno-rounding-math` so they kind of conflict?

I'd like to include enough in `-ffast-math` that the pattern-matching 
has a chance of matching standard code, but it's not hugely important so 
I'm OK if that relaxation of the semantics is not desirable.

On 7/31/26 22:41, Joseph Myers wrote:
> External email: Use caution opening links or attachments
> 
> 
> 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]
>