This is the mail archive of the
mailing list for the GCC project.
Re: Help w/ PR61538?
- From: Joshua Kinard <kumba at gentoo dot org>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 27 Jul 2014 23:56:57 -0400
- Subject: Re: Help w/ PR61538?
- Authentication-results: sourceware.org; auth=none
- References: <53B8C5F1 dot 9060005 at gentoo dot org>
On 07/05/2014 23:43, Joshua Kinard wrote:
> I filed PR61538 about two weeks ago, regarding gcc-4.8.x and up not
> compiling a g++/pthreads-linked app correctly on SGI R1x000-based systems
> (Octane, Onyx2), running Linux. Running the subsequently-compiled
> application simply hangs in a futex syscall until terminated via Ctrl+C. I
> suspect it's a double-locking bug of some design, as evidenced by strace
> showing two consecutive syscall()'s w/ 0x108e passed as the syscall # (4238
> or futex on o32 MIPS), but I am stumped as to what else I can do to debug it
> and help fix it.
> Full details:
So I've spent the last few weeks bisecting the gcc tree, and I've narrowed
down the set of commits that appear to have introduced this problem:
1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0 * config/mips/mips.c
2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c * config/mips/constraints.md
(ZR): New constraint.
3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953 * config/mips/mips.c
(mips_process_sync_loop): Emit cmp result only if
4. 30c3c4427521f96fb58b6e1debb86da4f113f06f * emit-rtl.c
(need_atomic_barrier_p): New function.
There's a build failure somewhere in the middle of there that is blocking me
from figuring out which specific one is the cause, but they all appear to be
related anyways. All four were added on 2012-06-20.
When I took a git checkout from 2012-06-26 and reverted those four commits,
I was able to compile glibc-2.19 and get a working "sln" binary. I am
unable to easily test the C++ side because I built the checkouts in my
$HOME, and it's too risky to try and shoehorn one of them in as the system
compiler. However, I think the C++ issue is also fixed by reverting the
four, as that also involved hanging in Linux futex syscalls.
Obviously, reverting these four commits is obviously not an option for gcc
releases, as over the last two years, a lot of code has been added that uses
some of the new bits (like the ZR constraint). So do any of the gcc MIPS
people have an idea what in these four commits could possibly be breaking
R1x000-series CPUs on SGI systems under gcc-4.8 and gcc-4.9, so a proper
patch can be made?
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic