https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #11 from Joshua Kinard <kumba at gentoo dot org> --- I also have another test case from glibc itself, where when compiling glibc-2.19 w/ gcc-4.8.x or greater, at the end, it creates a statically-linked version of 'ln' as 'sln', and tries to run that. That binary also hangs, but it hangs in glibc-specific code: nptl/sysdeps/unix/sysv/linux/lowlevellock.c: >¦32 while (atomic_exchange_acq (futex, 2) != 0) ¦33 lll_futex_wait (futex, 2, LLL_PRIVATE); ¦34 } Which looks like it's hanging in lll_futex_wait(). If I set a breakpoint on that address in the asm layout, I can see this: Breakpoint 1, 0x00423bf4 in __lll_lock_wait_private (futex=0x4a215c <_IO_stdfile_1_lock>) at ../nptl/sysdeps/unix/sysv/linux/lowlevellock.c:33 ¦0x423be0 <__lll_lock_wait_private+32> 0x7c03e83b ¦0x423be4 <__lll_lock_wait_private+36> li a2,2 ¦0x423be8 <__lll_lock_wait_private+40> lw a1,-29832(v1) ¦0x423bec <__lll_lock_wait_private+44> move a3,zero ¦0x423bf0 <__lll_lock_wait_private+48> li v0,4238 B+>¦0x423bf4 <__lll_lock_wait_private+52> syscall (gdb) x/6i 0x4a215c 0x4a215c <_IO_stdfile_1_lock>: srl zero,zero,0x0 0x4a2160 <_IO_stdfile_1_lock+4>: nop 0x4a2164 <_IO_stdfile_1_lock+8>: nop 0x4a2168 <_IO_stdfile_0_lock>: nop 0x4a216c <_IO_stdfile_0_lock+4>: nop 0x4a2170 <_IO_stdfile_0_lock+8>: nop I did find two very recent patches on libc-alpha that deal specifically with lowlevellock.h, by replacing it (and all other arch-specific variants) with a generic lowlevellock.h file: https://sourceware.org/ml/libc-alpha/2014-06/msg00174.html https://sourceware.org/ml/libc-alpha/2014-06/msg00419.html And this interesting comment: https://sourceware.org/ml/libc-alpha/2014-06/msg00184.html I am going to try rebuilding glibc with those and see if I am still getting hangs or not.