https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
Bug ID: 70560 Summary: Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Thomas pointed out at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01159.html that we test for atomics that work on bool, short and int when defining _GLIBCXX_ATOMIC_BUILTINS, and then if that's defined we use atomics on _Atomic_word: # Set atomicity_dir to builtins if all but the long long test above passes. if test "$glibcxx_cv_atomic_bool" = yes \ && test "$glibcxx_cv_atomic_short" = yes \ && test "$glibcxx_cv_atomic_int" = yes; then AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS, 1, [Define if the compiler supports C++11 atomics.]) atomicity_dir=cpu/generic/atomicity_builtins fi But _Atomic_word might not be one of those types, e.g. for sparc: #ifdef __arch64__ typedef long _Atomic_word; #else typedef int _Atomic_word; #endif The choice of atomicity_dir (i.e. whether to use atomics for _Atomic_word or not) should be based on tests that actually use that type, and that type only. I think it should be OK to relax the checks so that atomic builtins are used for _Atomic_word on targets where _GLIBCXX_ATOMIC_BUILTINS previously wasn't defined. In that case new code would use the builtins via the inline functions in <ext/atomicity.h>, and old code would continue to use the non-inline functions defined in libstdc++.so. Those non-inline functions would now come from cpu/generic/atomicity_builtins/atomicity.h and so would also use atomic builtins. It would not be OK to stop using atomics for _Atomic_word on targets where _GLIBCXX_ATOMIC_BUILTINS was previously defined. In that case, old code would use the inlined builtins but new code would call non-inline functions in cpu/generic/atomicity_mutex/atomicity.h (or a target-specific one) which might expect to be able to use non-atomic operations protected by a critical section. That expectation would not hold if other code is modifying the shared variable directly, outside the critical section. We could also review whether the __atomic_add_dispatch and __exchange_and_add_dispatch functions in <ext/atomicity.h> really give much benefit for anything except the old COW std::string. For std::shared_ptr, std::future etc. it might make sense to simplify things and use atomics unconditionally without checking __gthread_active_p().