https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |redi at gcc dot gnu.org
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to palmer from comment #3)
> 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.
It's definitely an ABI break. You can't pass a std::shared_ptr (or anything
using it, like std::future) between translation units that disagree about the
atomics policy.
> 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).
But user code can use std::shared_ptr and other reference-counted types, and
inline those functions. This isn't just about libstdc++.so itself.
> 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.
You don't need to do anything fancy like that to hit the problem. Just two
translation units, one compiled with the old gcc and one compiled with the new.
> It looks like LLVM already has inline atomics, so presumably the same issues
> would arise when mixing libstdc++ libraries compiled with LLVM and GCC.
Yup.
