http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-04
20:22:57 UTC ---
I can reproduce this with -m32 on gcc110
If I compile with -D_GLIBCXX_ATOMIC_BUILTINS then I no longer get the
double-free, after running in a loop for several minutes - can you confirm
that?
That implies the bug is in the non-atomic builtin fallback code in
config/cpu/generic/atomicity_mutex/atomicity.h which defines __exchange_and_add
like so:
_Atomic_word
__attribute__ ((__unused__))
__exchange_and_add(volatile _Atomic_word* __mem, int __val) throw ()
{
__gnu_cxx::__scoped_lock sentry(get_atomic_mutex());
_Atomic_word __result;
__result = *__mem;
*__mem += __val;
return __result;
}
This basically does a pthread_mutex_lock on a function-local static
pthread_mutex_t. Could this also be a problem in the underlying pthread lib?
I was surprised that _GLIBCXX_ATOMIC_BUILTINS is not automatically defined, but
indeed 32/libstdc++-v3/config.log shows:
configure:15247: checking for atomic builtins for long long
configure:15276: /home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/home/jwakely/build/./gcc -nostdinc++
-L/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/bin/
-B/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/include -isystem
/home/jwakely/gcc/4.x/powerpc64-unknown-linux-gnu/sys-include -m32 -fPIC
-mstrict-align -o conftest -g -O2 -D_GNU_SOURCE -fno-exceptions conftest.cpp
>&5
/tmp/cck5YUAJ.o: In function `main':
/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/conftest.cpp:30:
undefined reference to `__atomic_fetch_add_8'
/home/jwakely/build/powerpc64-unknown-linux-gnu/32/libstdc++-v3/conftest.cpp:32:
undefined reference to `__atomic_compare_exchange_8'
It seems unfortunate that we can't use __exchange_and_add on a 4-byte int just
because the platform doesn't provide atomic ops for 64-bit types.
