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]
