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]
