[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Joshua Kinard changed: What|Removed |Added Version|4.8.0 |4.9.3 Known to fail||4.9.3 Severity|major |critical --- Comment #23 from Joshua Kinard --- Any chance someone from the MIPS side can take a look at this PR and figure out a solution? I cannot find a way to sanely-intercept the glibc build and get the preprocessed output of 'sln.c'. glibc's build system is just too complex to figure out. I reconfirmed the problem using gcc-4.9.3 20150119 (prerelease), by building it from the gcc-4_9-branch git branch, so this bug is still present. Still only seems to affect R1, R12000, and R14000-based systems. Can easily reproduce on both an Octane (IP30) and Onyx2 (IP27). RM7000-based SGI O2 (IP32) does not seem to be affected, but I have not had that machine powered up lately to get a reverification.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #24 from Joshua Kinard --- This might have been inadvertently fixed by this patch: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02282.html Which is commit 0d18e650 in the master branch. Can't pin down when that was merged into the 4.9 branch. I backported the patch to gcc-4.9.2 and rebuilt that, and can now compile Python-3.3 w/o issue. Going to test the glibc case next and see if elf/sln will execute or not.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #25 from Andrew Pinski --- (In reply to Joshua Kinard from comment #24) > This might have been inadvertently fixed by this patch: > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02282.html I don't think it was inadvertently fixed by that patch, rather that patch is the correct fix for this bug; just not mentioning this bug report as the person did not know about it. So closing as fixed.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #21 from Andrew Pinski --- (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?
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
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.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 Joshua Kinard changed: What|Removed |Added Component|c++ |regression Version|4.9.0 |4.8.0 See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=516548 Summary|g++ compiled binary, linked |gcc after commit 39a8c5ea |to glibc libpthread, hangs |produces bad code for MIPS |on SGI MIPS R1x000 systems |R1x000 CPUs |on Linux| --- Comment #18 from Joshua Kinard --- Known to work: Prior to commit 39a8c5ea (2012-06-19) Known to fail: Anything after commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 (2012-06-20)
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #19 from Joshua Kinard --- Created attachment 33165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33165&action=edit Disassembly of the ASM from 'sln' compiled by a known 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 GOOD gcc-4.8.0 checkout (7882e02e) with commits 39a8c5ea, 974f0a74, 0f8e46b1, and 30c3c442 reversed.
[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #20 from Joshua Kinard --- Created attachment 33166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33166&action=edit 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.
