public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.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 [thread overview]
Message-ID: <bug-61538-4-3cadRL3wEz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
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.
next prev parent reply other threads:[~2014-10-21 6:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 17:31 [Bug c++/61538] New: g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux kumba at gentoo dot org
2014-06-17 18:07 ` [Bug c++/61538] " kumba at gentoo dot org
2014-06-18 16:55 ` redi at gcc dot gnu.org
2014-06-18 22:06 ` kumba at gentoo dot org
2014-06-19 1:11 ` pinskia at gcc dot gnu.org
2014-06-19 1:54 ` kumba at gentoo dot org
2014-06-19 4:58 ` kumba at gentoo dot org
2014-06-21 1:21 ` kumba at gentoo dot org
2014-06-21 1:59 ` kumba at gentoo dot org
2014-07-06 20:29 ` kumba at gentoo dot org
2014-07-15 5:02 ` pinskia at gcc dot gnu.org
2014-07-15 6:42 ` kumba at gentoo dot org
2014-07-15 7:38 ` pinskia at gcc dot gnu.org
2014-07-21 7:00 ` kumba at gentoo dot org
2014-07-21 7:10 ` [Bug regression/61538] gcc after commit 39a8c5ea produces bad code for MIPS R1x000 CPUs kumba at gentoo dot org
2014-07-21 7:17 ` kumba at gentoo dot org
2014-10-21 6:04 ` pinskia at gcc dot gnu.org
2014-10-21 6:30 ` kumba at gentoo dot org [this message]
2015-02-16 6:41 ` kumba at gentoo dot org
2015-02-18 8:22 ` kumba at gentoo dot org
2015-02-18 9:24 ` pinskia at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-61538-4-3cadRL3wEz@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).