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().
