From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17717 invoked by alias); 15 Jul 2014 06:42:46 -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 17587 invoked by uid 48); 15 Jul 2014 06:42:36 -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: Tue, 15 Jul 2014 06:42: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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00937.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #14 from Joshua Kinard --- (In reply to Andrew Pinski from comment #13) > What is the kernel version? There has been some recent (this year) fixes > inside the kernel for futex. > > Though I admit I have seen this just recently when debugging a program where > I did next over a pthread_mutex_unlock call. Was under 3.14.x. I already tried going back to 3.14.0, due to the recent futex security flaws covered in CVE-2014-3153. Now on 3.15.5 on the Octane, and my test binaries still hang, so I've pretty much ruled out it being the kernel. I've been doing a git bisect of gcc the last few days, and I've pinned the problem commit down to somewhere between Jun 12 2012 and June 26 2012. anything prior to the 26th works so far, anything after doesn't. My current bisect build is going to test June 19 2012 next. Averages about ~7.5hrs for gcc and 3.5hrs for glibc to build, so I can cram in roughly, 2 tests a day. So far, I am leaning towards commit 30c3c4427521f96fb58b6e1debb86da4f113f06f as the culprit. That was added on June 20th, and I *think* the refactoring of the case statement is wrong for MIPS. The logic just doesn't seem to work out to be the same as the old code it replaced, and maybe this only is a problem on the R10000 processors. So if my build for June 19 2012 works, then a another 'git bisect good' should put me somewhere between the 23rd/24th, and if that's bad, I'm going to then try to test a gcc checkout both with and without that one commit to verify if it's the bug or not. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=30c3c4427521f96fb58b6e1debb86da4f113f06f