On Wednesday, 23 August 2023 12:12:09 PDT Myria via Std-Discussion wrote:
> According to the Standard, when using std::atomic<float>::fetch_add etc.,
> operations that would result in a value of range, an unspecified value
> results rather than undefined behavior. This is like how overflowing a
> std::atomic<int> is well-defined unlike just int.
>
> The Standard says that such float fetch_add operations may use a different
> floating-point environment than the calling function.
>
> If the calling thread has floating-point exceptions enabled, and one of the
> atomic operations would trigger in an addition / subtraction, what should
> happen?
>
> MSVC, libc++ and libstdc++ all will throw the exception.

>From the wording, those implementations would be constrained to mask
exceptions or intercept them, continuing from recovery code. It sounds like
those implementations are buggy.

>From the point of view of implementations, the standard is the one that needs
to be fixed. Until we have per-instruction "suppress exception" mode (on x86,
that's only available with AVX512 and AVX10), atomic FP operations would need
to repeatedly save, update, and restore the FP environment, which aren't
trivial instructions. However, given that CPUs usually don't have atomic FP
operations anyway, implementations will likely need to lock mutexes around the
non-atomic ops, so the cost of modifying the FP environment may be acceptable.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering