https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #10 from palmer at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #6) > > (In reply to Jonathan Wakely from comment #5) > > > (In reply to palmer from comment #3) > > > > 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. > > > > But not just "when mixing libstdc++ libraries". When mixing pretty much any > > C++ code that uses libstdc++ headers. > > Oh actually, sorry, that's wrong. The atomic policy for libstdc++ is set at > configure time, based on the GCC building it. We define a macro, and that is > fixed for the lifetime of that libstdc++ installation. So it doesn't matter > if you compile those same headers with Clang, which _could_ use atomic > built-ins, the atomic policy is still decided by the macro which doesn't > change after installation. > > So it's only a problem when mixing user code compiled with old and new > libstdc++ headers. > > And I've been confusing the _GLIBCXX_ATOMIC_BUILTINS macro with the > _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro. I hadn't even noticed the _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY macro, thanks! > If _GLIBCXX_ATOMIC_BUILTINS changes from undefined to 1, I think that's OK. > Old code will still call the non-inline functions in libstdc++.so, but those > will now be consistent with the inline ones that new code is calling. My specific worry was users mixing in routines from two different versions of libstdc++: for example, maybe there's some statically linked executable that puts a shared pointer into a mmap'd region, which it then expects to work when After signing off last night I realized that none of that would work anyway, though, as even with the same library on both ends users would end up with a different mutex and thus races. So I think that one isn't worth worrying about. [snip, I'm mixing two replies here] > Thanks. Changing that will cause an ABI break in the headers (and so affect > user code, not just the libstdc++.so library). > > Clang and GCC will still be compatible, because the macros are still set > once by configure when building libstdc++. >From my reading of this, GCC and clang will build libstdc++ binaries with incompatible ABIs: clang has inline atomics, so the 2-byte CAS check will succeed and we'll end up with libstdcxx_atomic_lock_policy=atomic . I don't actually have a clang build around to test that with, though, and I'm not sure if folks are shipping clang-built libstdc++ anywhere (and if so, are expecting it to be compatible with a GCC-built libstdc++). > One solution would be to override the checks in libstdc++-v3/acinclude.m4 so > that _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY is also #undef for RISC-V, even after > the atomic built-ins are supported. That would preserve the ABI, but would > mean ref-counting in libstdc++ is sub-optimal. > > Or let the default change, and vendors who want to preserve the old ABI can > configure with --with-libstdcxx-lock-policy=mutex to override the default. I guess I'm not really sure here: normally I'd say we're stuck with the default being ABI compatible, but I don't know the rules in libstdc++. I'm assuming that forcing the default to be mutex could still allow users who want atomic to configure with --with-libstdcxx-lock-policy=atomic, so at least there's a path forward. IIUC users will get link errors when moving between the two flavors (the explicit template instantiations will have different integer values), so at least there's a way for distros to make sure they've re-built everything if they want to change. I could also imagine a much more complicated third option: essentially upgrading the mutex to an RW-like lock and allowing the atomic-based routines to proceed concurrently. I poked around the locking code a bit have no idea if this would even be possible, it's all complicated enough that it seems like at best a bad idea. I guess this is really a distro sort of question, but I'd lean towards forcing the default to mutex on RISC-V, thus keeping ABI compatibility. Then at least the distros can pick if they want to have a flag day around this.
