[Bug c++/61538] New: g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux

["kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538

            Bug ID: 61538
           Summary: g++ compiled binary, linked to glibc libpthread, hangs
                    on SGI MIPS R1x000 systems on Linux
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kumba at gentoo dot org
                CC: toolchain at gentoo dot org
              Host: mips-unknown-linux-gnu
            Target: mips-unknown-linux-gnu
             Build: mips-unknown-linux-gnu

I appear to have run into a regression in g++/libstdc++, starting with at least
4.8.2, where a simple binary built by g++ and linked to glibc-2.19's libpthread
causes the binary to hang on a kernel futex() syscall (syscall #4328 in o32
ABI) until killed or interrupted w/ ctrl-C.

I have replicated this problem in an o32 environment, as well as an n32 and n64
multilib environment.

So far, the identified trigger conditions are:
- Must be an R10000-based SGI system (SGI O2 w/ RM7000 does not reproduce)
- Must compile testcase w/ 'g++' (compiling with 'gcc' works fine)
- Must link w/ -lpthread from at least glibc-2.19 (doesn't seem to trigger on
older versions).
- Must be gcc-4.8.2 or greater (gcc-4.6.4 and gcc-4.7.3 both work fine).

I ran into this while getting Linux support for the SGI Octane operational
again and rebuilding a ~5-year old Gentoo userland on the machine.  I at first
thought it was a problem with old libs still living on the system that I
haven't purged just yet, but I have been able to recreate the problem in a
clean n32/n64 Gentoo stage3 chroot.

The Octane in particular has an R14000 CPU module installed right now, though I
can also trigger the condition on an R12000 CPU module as well.  I don't have
any other working R1x000-capable SGI hardware available at the moment to test
this on, so this could still be a quirky bug in the Octane's kernel, but I
believe this is less likely since I can trigger the problem only with specific
versions of libstdc++.

Sample C code that I can use to trigger the issue with from Python-3.3.5's
configure script (where it etsts for thread support):
# cat conftest.c
void foo();int main(){foo();}void foo(){}

Compiler command line:
# g++ -o conftest conftest.c -lpthread

# ./conftest
<hang>

Overriding LD_PRELOAD to use libstdc++ from an earlier gcc:

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/libstdc++.so.6
./conftest
<hang>

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
./conftest
<hang>

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.7.3/libstdc++.so.6
./conftest
<returns>

I don't have much more than that at the moment, but let me know if there are
specific command outputs needed to further determine what the cause of this
problem is.