http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-10
15:36:40 UTC ---
You're quite right, my apologies for telling you that wouldn't happen.
In bits/shared_ptr_base.h we have:
template<>
inline void
_Sp_counted_base<_S_atomic>::
_M_add_ref_lock()
{
// Perform lock-free add-if-not-zero operation.
_Atomic_word __count = _M_use_count;
do
{
if (__count == 0)
__throw_bad_weak_ptr();
// Replace the current counter value with the old value + 1, as
// long as it's not changed meanwhile.
}
while (!__atomic_compare_exchange_n(&_M_use_count, &__count, __count + 1,
true, __ATOMIC_ACQ_REL,
__ATOMIC_RELAXED));
}
This will always be atomic if __default_lock_policy is _S_atomic
The problem is in ext/concurrence.h:
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
This is inconsistent with the definition of _GLIBCXX_ATOMIC_BUILTINS and means
that on power shared_ptr thinks it can use atomics, but the "dispatch"
functions in ext/atomicity.h don't use atomics.
__default_lock_policy should not say to use atomics if the dispatch functions
don't use atomics.
A quick fix would be to only set __default_lock_policy=_S_atomic if
_GLIBCXX_ATOMIC_BUILTINS is also defined
