http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-05 13:02:53 UTC --- (In reply to comment #17) > I wonder if the problem is that libstdc++ is using both atomics and > pthread_mutex protected manipulation of the same variable? That of course > would fail. I'm pretty sure that can't happen. We always access those variables consistently through a single API, which would always use a mutex or never use a mutex. > Looking at libstdc++ with objdump, I do see quite a few > occurrences of lwarx even though _GLIBCXX_ATOMIC_BUILTINS is undefined. These > are the functions: > > atomic_flag_test_and_set_explicit > _ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception > _ZNSt15__exception_ptr13exception_ptr9_M_addrefEv > _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv > _ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE > _ZL22free_any_cxa_exceptionP17_Unwind_Exception > _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception > __cxa_guard_acquire > __cxa_guard_abort > __cxa_guard_release That looks correct, none of those depends on _GLIBCXX_ATOMIC_BUILTINS Could the problem be the initialization of the function-local static, rather than in locking it later. That initialization should be thread-safe, that's what __cxa_guard_acquire and __cxa_guard_release are used for: http://sourcery.mentor.com/public/cxx-abi/abi.html#once-ctor
