[Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs

["kumba at gentoo dot org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538

--- Comment #22 from Joshua Kinard <kumba at gentoo dot org> ---
(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.