Hi, I have come across something which I believe is a bug in g++. I've seen this issue both in 4.9.1 and 5.2.0, but I'm struggling to create a small testcase. (The output of g++ -v for 5.2.0 is below.) The issue is a deadlock that seems to be due to there being (runtime) the equivalent of _two_ different variables __gthread_active_ptr. It just so happens that in the libstdc++ pool allocator template, the allocate() function, for a certain instantiation, is compiled so that the lock() method of the __scoped_lock (in ext/concurrence.h) is getting 'true' as the result of its call to __gthread_active_p(), while in the unlock() method it gets 'false'. The next allocation of the same type will of course deadlock due to not releasing the mutex after the previous allocation. Looking at the assembly code, in the unlock() method the code if (__gthread_active_p()) is actually reduced to mov $0x0,%eax test %eax,%eax so somehow g++ managed (erroneously) to fold this runtime-test during compile time (at least that is my guess). In the lock() method it looks like this: mov $0xf6610f40,%eax test %eax,%eax Note that this is not the case for all instantiations of the pool allocator template, but it is indeed the case for this particular type. I'm seeing this already at -O1 (-O0 is fine, no deadlock). Now, I tried to bisect whatever options -O1 implies by looking at what g++ -Q -O1... produced, but it turns out that when I use the full list of options (except for -fleading-underscore and -fgnu-runtime, which obviously are not actually used for my -O1 compile, as either the compiler complains that I'm not using LTO or the linker complains about ___dso_handle being undefined for libstdc++ code) I don't get the deadlock anymore. I've also tried to remove as much code as possible and managed to reduce the amount of code needed a to trigger the issue a bit but further reductions have all resulted in the deadlock vanishing. Moreover, I tried using both gold and ld (two different versions) to try to rule out this being a linker issue, but all cases deadlock. Is there some other options (maybe internal) to g++ I could try? Any other ideas to be able to come up with a small testcase? I'd be happy for any advice. Thanks, /Johan Alfredsson bash> /usr/local/products/gcc/5.2.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/products/gcc/5.2.0/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/products/gcc/5.2.0/lib/gcc/x86_64-suse-linux/5.2.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../../gcc-5.2.0/configure --enable-languages=c,c++,fortran --enable-targets=x86_64-suse-linux,i686-suse-linux --prefix=/usr/local/products/gcc/5.2.0 --with-gnu-as --with-as=/usr/local/products/gcc/binutils-2.25.1/bin/as --with-gnu-ld --with-ld=/usr/local/products/gcc/binutils-2.25.1/bin/ld.gold --with-gmp=/usr/local/products/gcc/gmp-5.0.1 --with-mpfr=/usr/local/products/gcc/mpfr-3.0.0 --with-mpc=/usr/local/products/gcc/mpc-0.8.2 --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool x86_64-suse-linux Thread model: posix gcc version 5.2.0 (GCC)
