From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22586 invoked by alias); 21 Oct 2014 06:04:45 -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 22546 invoked by uid 48); 21 Oct 2014 06:04:39 -0000 From: "kumba at gentoo dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs Date: Tue, 21 Oct 2014 06:30:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: regression X-Bugzilla-Version: 4.8.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-10/txt/msg01570.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #22 from Joshua Kinard --- (In reply to Andrew Pinski from comment #21) > (In reply to Joshua Kinard from comment #20) > > Created attachment 33166 [details] > > Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0. > > > > This is the objdump disassembly of the '__lll_lock_wait_private()' function > > from the sln binary from glibc, statically compiled, by a BAD gcc-4.8.0 > > checkout (7882e02e) no previous commits reversed. This sln copy will hang > > trying to print usage instructions. > > Do you have the preprocessed source for this? Not currently. I'd have to intercept a glibc build and grab the compile string for sln.c and use that to crate the preprocessed source. I'll see if I can start a run tonight or tomorrow for this. That said, I have worked out that it's got something to do with gcc's built-in atomics added for 4.8. In glibc's sysdeps/mips/bits/atomic.h, there are conditional macros that pick whether to use the old __sync_* builtins if gcc-4.7 and earlier, or the new __atomic_* builtins in gcc-4.8 or later. This is why there is a difference between the output assembler between the 4.7 and 4.8 sln files. Under gcc-4.7, atomic_exchange_acq falls back to __sync_lock_test_and_set, which is an acquire memmodel operation, and this works fine on an R14000 processor. It's under gcc-4.8+, whatever atomic_exchange_acquire() maps to there, that hangs up on the processor. I checked the kernel side, and the futex is getting lost in freezable_schedule() in include/linux/freezer.h. I haven't traced beyond that point yet. The futex will exit the scheduler when you ctrl+c it. If you delete or comment out the gcc-4.8 defines for the atomic ops in sysdeps/mips/bits/atomic.h in glibc to force it back to the older __sync_* ops, it'll build with 4.8+ and the resulting sln WILL work. So it's definitely a gcc issue. I got a hold of Maxim Kuvyrkov regarding commit 39a8c5ea, but I haven't heard back from him since early September, despite sending two follow-up e-mails.