From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11507 invoked by alias); 18 Jun 2014 22:06:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 11468 invoked by uid 48); 18 Jun 2014 22:06:08 -0000 From: "kumba at gentoo dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux Date: Wed, 18 Jun 2014 22:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: kumba at gentoo dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01601.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61538 --- Comment #3 from Joshua Kinard --- (In reply to Jonathan Wakely from comment #2) > Can you provide a stack trace to show which constructor/destructor it's > hanging in? Hopefully you mean a backtrace from gdb. Not finding a lot of info on doin= g a C++ stacktrace (I haven't messed with C++ in years). The testcase isn't stripped and has debugging info, but glibc-2.19, and gcc-4.8.2 are stripped and built w/o debugging, so the backtrace doesn't provide a lot of info. I might be able to rebuild them w/ debugging, but g= cc takes almost 13+ hours on the Octane to build, while glibc takes another 3-= 4. First, here is what strace shows: set_tid_address(0x7797f2e8) =3D 2532 set_robust_list(0x7797f2f0, 12) =3D 0 futex(0x7fb06690, FUTEX_WAKE_PRIVATE, 1) =3D 0 futex(0x7fb06690, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, = 0) =3D -1 EINVAL (Invalid argument) rt_sigaction(SIGRT_0, {0x8, [], SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_NOCLDWAIT|0x7921a94}, NULL, 16) =3D 0 rt_sigaction(SIGRT_1, {0x10000008, [], SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x7921940}, NULL, 16) =3D 0 rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) =3D 0 getrlimit(RLIMIT_STACK, {rlim_cur=3D8192*1024, rlim_max=3D2147483647}) =3D 0 syscall(0x108e, 0x77929500, 0, 0, 0, 0, 0x77929160) =3D -1 EAGAIN (Resource temporarily unavailable) syscall(0x108e, 0x77929500, 0, 0x10100, 0, 0, 0x77929160 That last line is where you see it hanging until I send ctrl+c, with the fi= rst argument to both being 0x108e (4238 in decimal, I typoed it as '4328' in my original post), which is a futex call, per mips-o32-linux.xml in GDB: Running in GDB, setting a catchpoint on syscall 4238 and upping the heuristic-fence-post limit a fair bit to quiet some warnings down: This first catchpoint doesn't hang: =C2=A60x77f9dc1c <__pthread_initialize_minimal_internal+148> addiu a0,s8= ,32 =C2=A60x77f9dc20 <__pthread_initialize_minimal_internal+152> li a1,129 =C2=A60x77f9dc24 <__pthread_initialize_minimal_internal+156> li a2,1 =C2=A60x77f9dc28 <__pthread_initialize_minimal_internal+160> li v0,42= 38 =C2=A60x77f9dc2c <__pthread_initialize_minimal_internal+164> syscall >=C2=A60x77f9dc30 <__pthread_initialize_minimal_internal+168> bnez a3,0x= 77f9df9c <__pthread_initialize_minimal_internal+1044> Catchpoint 1 (call to syscall 4238), 0x77f9dc30 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 (gdb) thread apply all bt Thread 1 (process 2584): #0 0x77f9dc30 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 #1 0x77f9c5a4 in _init () from /lib/libpthread.so.0 Cannot access memory at address 0x77fc3ffe Here's the second catchpoint for syscall #4238: =C2=A60x77f9dc64 <__pthread_initialize_minimal_internal+220> addiu sp,sp= ,-32 =C2=A60x77f9dc68 <__pthread_initialize_minimal_internal+224> sw v0,16= (sp) =C2=A60x77f9dc6c <__pthread_initialize_minimal_internal+228> li v0,42= 38 =C2=A60x77f9dc70 <__pthread_initialize_minimal_internal+232> syscall >=C2=A60x77f9dc74 <__pthread_initialize_minimal_internal+236> addiu sp,sp= ,32 Catchpoint 1 (call to syscall 4238), 0x77f9dc74 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 (gdb) thread apply all bt Thread 1 (process 2584): #0 0x77f9dc74 in __pthread_initialize_minimal_internal () from /lib/libpthread.so.0 #1 0x77f9c5a4 in _init () from /lib/libpthread.so.0 Cannot access memory at address 0x77fc3ffe After I type continue again, it hangs until interrupted: (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x77d50864 in syscall () from /lib/libc.so.6 (gdb) thread apply all bt Thread 1 (Thread 0x77feb000 (LWP 2591)): #0 0x77d50864 in syscall () from /lib/libc.so.6 #1 0x77ed9160 in __cxa_guard_acquire () from /usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6 #2 0x77f4325c in std::future_category() () from /usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6 #3 0x77ed406c in ?? () from /usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6 Cannot access memory at address 0x77fc3ffe (gdb) >>From gcc-bugs-return-454520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 18 22:12:36 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17474 invoked by alias); 18 Jun 2014 22:12:35 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 17242 invoked by uid 55); 18 Jun 2014 22:12:30 -0000 From: "kkojima at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/61550] [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943 Date: Wed, 18 Jun 2014 22:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: kkojima at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg01602.txt.bz2 Content-length: 462 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61550 --- Comment #2 from Kazumoto Kojima --- Author: kkojima Date: Wed Jun 18 22:11:55 2014 New Revision: 211807 URL: https://gcc.gnu.org/viewcvs?rev=211807&root=gcc&view=rev Log: PR target/61550 * config/sh/sh.c (prepare_move_operands): Don't process TLS addresses here if reload in progress or completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c