On Mon, 14 Oct 2024 at 14:35, Jonathan Wakely <jwak...@redhat.com> wrote: > > 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'm not sure if C++ users really care about fenv. I think most don't. > > > > 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 > >
