Attempting to resend since got rejected from gcc-patches mailing list.
(Apologies about the duplication to those on Cc).
On 11/18/24 11:25, Matthew Malcomson wrote:
On 11/14/24 18:44, Joseph Myers wrote:
External email: Use caution opening links or attachments
On Thu, 14 Nov 2024,mmalcom...@nvidia.com wrote:
N.b. I would appreciate any feedback about how one should handle such a
situation when working with C11 _Atomic types. They have the same
problem that they require libatomic and sometimes libatomic is not
available. Is this just something that will stay as a known limitation
for certain platforms? Is there something in the works to make it more
viable?
libatomic, like libgcc, is part of the language support - you can't get
full language support (including e.g. support for _Atomic structures)
without sometimes needing to link with libatomic. Disabling libatomic
means you don't have full language support. (It's possible you need to
add more libatomic support for particular OS configurations, or arrange
some system for responsibility to be split between libatomic and a board
support package linked in with custom linker scripts if the way to do e.g.
locking for large _Atomic operations genuinely depends on details of the
RTOS in use where a *-elf target is used with GCC that doesn't know about
those details. But ultimately, whether provided by libatomic or a BSP,
code needs to be linked in to provide certain interfaces required for full
_Atomic support.)
Ah, I see -- thanks for the clarification.
Based on that -- should the same reasoning apply to the new builtins?
I.e. do you believe it would be reasonable to say that the new builtins
require libatomic, and remove this flag entirely?
(Or possibly just keep it hidden from the user and only available as a
developer flag for things like testing).
--
Joseph S. Myers
josmy...@redhat.com
