[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux

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

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

--- Comment #16 from Joshua Kinard <kumba at gentoo dot org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Joshua Kinard from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > What is the kernel version?  There has been some recent (this year) fixes
> > > inside the kernel for futex.
> > > 
> > > Though I admit I have seen this just recently when debugging a program where
> > > I did next over a pthread_mutex_unlock call.
> > 
> > Was under 3.14.x.  I already tried going back to 3.14.0, due to the recent
> > futex security flaws covered in CVE-2014-3153.  Now on 3.15.5 on the Octane,
> > and my test binaries still hang, so I've pretty much ruled out it being the
> > kernel.
> > 
> > I've been doing a git bisect of gcc the last few days, and I've pinned the
> > problem commit down to somewhere between Jun 12 2012 and June 26 2012. 
> > anything prior to the 26th works so far, anything after doesn't.  My current
> > bisect build is going to test June 19 2012 next.  Averages about ~7.5hrs for
> > gcc and 3.5hrs for glibc to build, so I can cram in roughly, 2 tests a day.
> 
> I would try the daily date update right before
> 30c3c4427521f96fb58b6e1debb86da4f113f06f commit and then bispect from there
> because there are a few changes between the daily date update which could
> have caused this issue.

So I spent the last week bisecting as far as I can, but right around 20120620,
I keep running into the same build failure about ~3hrs into the build:

In file included from ../.././gcc/config/mips/mips.c:31:0:
../.././gcc/config/mips/mips.c: In function 'void mips_process_sync_loop(rtx,
rtx_def**)':
../.././gcc/rtl.h:632:48: error: invalid conversion from 'long long int' to
'memmodel' [-fpermissive]
 #define XCWINT(RTX, N, C)     ((RTX)->u.hwint[N])

In 'all-stage2-gcc'.  That's right around the commit you're referencing, so I
went ahead and reversed these four commits:

1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0  * config/mips/mips.c
(mips_emit_pre_atomic_barrier_p,)
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.

And am going to rebuild again and see if it either compiles or not.  If it does
compile, I'll rebuild glibc and see if the 'sln' binary works.  If so, then we
have the bad commits.  I think all four of them go together, so I don't know if
I can undo only one at a time.  Thoughts?  If I can save a day or two of
compiling, that'd be great.  Though, if these four are the problem, I still
have to find a way to undo them from at least 4.8.3 to verify the c++-side of
things w/ my original -lpthreads testcase.  But I don't know how deeply
ingrained these commits are now after ~2 years.

I am guessing the changes don't impact newer MIPS processors, but I am still
not sure why it's affecting only the R1x000-family.  I've looked over the
errata sheets I have, but nothing sticks out as a possible cause.  I doubt
these four commits can just be reversed entirely.  The actual problem has to be
found and worked around.