After getting GCC to handle floating point exceptions I'm now noticing that the `targetm.atomic_assign_expand_fenv` hook tends to use the library function `__atomic_feraiseexcept`. This requires adding -latomic to the command line where it wasn't needed before. I also notice that the inline CAS loop for libstdc++ `atomic<T>::fetch_add` on floating point types doesn't handle these floating point exceptions.
For context, clang (which has already implemented floating point fetch_add for floating point types) is not emitting anything to handle the floating point environment. I expect that the eventual goal should be (please do correct if you disagree) 1. Update the existing libstdc++ CAS loop to handle floating point exceptions. 2. Suggest to clang that the fetch_add builtin should handle floating point exceptions. 3. GCC builtin handles floating point exceptions. 4. __atomic_feraiseexcept should be a builtin to avoid previously unnecessary requirement to link libatomic. However I'm uncertain we could sort all that out for GCC 15. Would it be reasonable to require linking with libatomic for the GCC 15 release? Alternatively is there some other intermediate step that people would prefer? Similarly — maybe there's something I'm missing — maybe about differences between C/C++? Another option is to aim for implementing the functionality of __atomic_feraiseexcept inline in the fetch_add GCC 15 (a bit tight on time), to use it in the new fetch_add builtin overload, but not use it in the CAS loop. That way no compiler & floating point type combination would need linking libatomic, current clang would not handle floating point exception information, while current gcc would handle that information. What are your thoughts? Regards, Matthew ________________________________ From: Joseph Myers <josmy...@redhat.com> Sent: 19 September 2024 10:38 PM To: Matthew Malcomson <mmalcom...@nvidia.com> Cc: gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>; Jonathan Wakely <jwak...@redhat.com>; Richard Biener <rguent...@suse.de> Subject: Re: [PATCH 0/8] [RFC] Introduce floating point fetch_add builtins External email: Use caution opening links or attachments On Thu, 19 Sep 2024, mmalcom...@nvidia.com wrote: > 6) Anything special about floating point maths that I'm tripping up on? Correct atomic operations with floating-point operands should ensure that exceptions raised exactly correspond to the operands for which the operation succeeded, and not to the operands for any previous attempts where the compare-exchange failed. There is a lengthy note in the C standard (in C11 it's a footnote in 6.5.16.2, in C17 it's a Note in 6.5.16.2 and in C23 that subclause has become 6.5.17.3) that discusses appropriate code sequences to achieve this. In GCC the implementation of this is in c-typeck.cc:build_atomic_assign, which in turn calls targetm.atomic_assign_expand_fenv (note that we have the complication for C of not introducing libm dependencies in code that only uses standard language features and not <math.h>, <fenv.h> or <complex.h>, so direct use of <fenv.h> functions is inappropriate here). I would expect such built-in functions to follow the same semantics for floating-point exceptions as _Atomic compound assignment does. (Note that _Atomic compound assignment is more general in the allowed operands, because compound assignment is a heterogeneous operation - for example, the special floating-point logic in build_atomic_assign includes the case where the LHS of the compound assignment is of atomic integer type but the RHS is of floating type. However, built-in functions allow memory orders other than seq_cst to be used, whereas _Atomic compound assignment is limited to the seq_cst case.) So it would seem appropriate for the implementation of such built-in functions to make use of targetm.atomic_assign_expand_fenv for floating-point environment handling, and for testcases to include tests analogous to c11-atomic-exec-5.c that exceptions are being handled correctly. Cf. N2329 which suggested such operations for C in <stdatomic.h> (but tried to do to many things in one paper to be accepted into C); it didn't go into the floating-point exceptions semantics but simple correctness would indicate avoiding spurious exceptions from discarded computations. -- Joseph S. Myers josmy...@redhat.com
