https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> --- (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. 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. The problem for std::shared_ptr and similar ref-counts is if _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY changes from undefined to 1. What is the state of that macro on RISC-V today?
