N.B. please CC the libstdc++ list for libstdc++ topics. On Mon, 14 Oct 2024 at 14:00, Matthew Malcomson <mmalcom...@nvidia.com> wrote: > > 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.
Right, Joseph made the C front-end handle them for _Atomic but I didn't do that for std::atomic. > 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) > > Update the existing libstdc++ CAS loop to handle floating point exceptions. > Suggest to clang that the fetch_add builtin should handle floating point > exceptions. > GCC builtin handles floating point exceptions. > __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? That would be a regression for anybody using std::atomic<floating-point-type> today. > 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? If making it Just Work without a new libatomic requirement is possible, I'd prefer that. > 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 >
