libstdc++ fetch_add & fenv -- ecosystem questions

[Matthew Malcomson]

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 <josmyers@redhat.com>
Sent: 14 October 2024 6:47 PM
To: Matthew Malcomson <mmalcomson@nvidia.com>
Cc: Jonathan Wakely <jwakely@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
josmyers@redhat.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20241015/51413241/attachment.htm>