On Mon, 5 Jul 2021, Thomas Schwinge wrote: > But: why, what's the rationale? Are potential floating point exceptions > the problem, maybe? "Simply, because nobody bothered implementing it
__atomic_* more or less correspond to some of the atomic_* operations in <stdatomic.h>, which only include atomic_fetch_* for integer types. Atomic compound assignment for floating-point arithmetic is thus only possible in C via direct use of compound assignment operators on _Atomic objects - and thus only with seq_cst memory order. It would be reasonable to have built-in function support for floating-point compound assignment, in order to allow an explicit memory order to be specified. If that were to be supported for non-C languages, there's a lot of code in c-typeck.c:build_atomic_assign (including the use of targetm.atomic_assign_expand_fenv to deal with exceptions issues) that would need factoring out in some way to be usable for non-C. (Unless you want at least one of (a) explicit memory order or (b) non-C languages, just using compound assignment operators on _Atomic objects suffices.) It's less clear if the built-in functions handling floating-point like that should be the existing __atomic_fetch_* (cf. bug 64843 discussing how __atomic_fetch_add does not do the multiplication by element size for pointer types, and, if pointer types are to be supported for atomic_fetch_add, <stdatomic.h> might be a better place to deal with that adjustment than making the built-in function handle it). -- Joseph S. Myers jos...@codesourcery.com
