https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
palmer at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |palmer at gcc dot gnu.org
--- Comment #3 from palmer at gcc dot gnu.org ---
I'm not sure what the right way to go about fixing this is.
Assuming the inline atomics
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104338#c3> work out we'll end up
with libstdc++ using atomics when compiled with newer GCCs and using locks when
compiled with older GCCs. Those two implementations aren't compatible with
each other, as the direct atomics won't respect the lock. That certainly means
these two implementations can't coexist, but I'm not actually sure if this is
an ABI break because I don't know what the ABI surface is supposed to be here.
As far as I can tell simple uses cases are safe here, as __exchange_and_add
isn't inlined outside of the shared library (though I'm not seeing anything
guaranteeing that, so I may be wrong here). Doing something like trying to
mmap a shared_ptr and access from both flavors of the library (maybe one's
statically linked, for example) would also break, and I could imagine that
existing in real code.
It looks like LLVM already has inline atomics, so presumably the same issues
would arise when mixing libstdc++ libraries compiled with LLVM and GCC.
