Thanks for the pointer — always linking with libatomic by default
using--as-needed sounds quite promising from my end.
I am not certain, but suspect that needing libatomic for
atomic<float>::fetch_{add,sub} would not mean libstdc++.so would get a
DT_NEEDED for libatomic.
The place where the new builtin would go is in a header that the user code
would include (and would be inlined completely).
>From a quick grep it appears this functionality in this header is not
>currently used in the libstdc++.so library itself.
Not 100% confident on that yet — but enough to feel this approach is promising.
I guess if that is the case, then using the same hypothetical driver flag
suggested in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c9 for linking
libstdc++ seems like it could avoid adding the requirement without realising.
>From reading the comments in that bugzilla it doesn't look like there's any
>objection to implementing that.
Seems that the testsuite and build system are the main things to watch out for
here right?
Does that seem reasonable to others?
________________________________
From: Joseph Myers <josmy...@redhat.com>
Sent: 14 October 2024 6:47 PM
To: Matthew Malcomson <mmalcom...@nvidia.com>
Cc: Jonathan Wakely <jwak...@redhat.com>; gcc-patches@gcc.gnu.org
<gcc-patches@gcc.gnu.org>
Subject: Re: libstdc++ fetch_add & fenv -- ecosystem questions
External email: Use caution opening links or attachments
On Mon, 14 Oct 2024, Matthew Malcomson wrote:
> 4. __atomic_feraiseexcept should be a builtin to avoid previously
> unnecessary requirement to link libatomic.
libatomic should be linked by default (with --as-needed); see bug 81358.
But if your concern is e.g. libstdc++.so having DT_NEEDED for libatomic,
that might not suffice.
__atomic_feraiseexcept is a bit long to expand inline all the time (it's
supposed to ensure that exceptions are raised including taking any enabled
traps, so it's not just manipulating bits in the floating-point status
register). On the other hand, if you're only concerned with one
operation, only a subset of the checks in __atomic_feraiseexcept are
relevant (for example, addition and subtraction can't raise FE_DIVBYZERO;
and except for the exact underflow case which __atomic_feraiseexcept
doesn't handle anyway, they can't raise FE_UNDERFLOW).
--
Joseph S. Myers
josmy...@redhat.com
