[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #11 from Joshua Kinard  ---
(In reply to Joshua Kinard from comment #10)
> Created attachment 43166 [details]
> genrecog.ii temp data from failing build command

Forgot to add, this is generated from a checkout of commit id 1998c023a3ed,
which was the last "bad" build, per git bisect.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #10 from Joshua Kinard  ---
Created attachment 43166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43166=edit
genrecog.ii temp data from failing build command

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #9 from Joshua Kinard  ---
(In reply to Eric Botcazou from comment #8)
> > FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
> > compiles cleanly, which is the first time that's happened on this machine
> > under N32.  Successful builds on this machine take about 8 hours.  Fail
> > builds~3-4 hours.  It's during stage2-bubble when compiling genrecog.c
> > will bail out, claiming no more virtual memory (2GB RAM + 3GB of swap).
> 
> Can you invoke the problematic command manually and add -save-temps to it? 
> This will give you a .i file, then gzip it and attach it to the PR.

Yup, I'll attach that in a moment.  I also have the 'genrecog.s' file, if
needed.  I'll also add that it takes the command about 20-25mins to fail, which
is very abnormal.  This machine might be old, but the CPUs are 600MHz, and they
can still chew through some of the largest C/C++ source files in under a minute
in most cases.  So it seems like something in the stage2-bubble xgcc/xg++ gets
stuck in a loop and consumes additional memory with each iteration until it
hits some kind of boundary and bails.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #7 from Joshua Kinard  ---
(In reply to Eric Botcazou from comment #6)
> Please retry with the current 7 branch, it contains additional fixes.

I did about a week ago.  Tried building gcc-7-branch HEAD with both gcc-6.4.0
and gcc-5.3.0, and both failed in the same spot.  If something was added in the
last week, I can re-test.  I also tried gcc-HEAD with gcc-6.4.0 and that also
failed.

FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
compiles cleanly, which is the first time that's happened on this machine under
N32.  Successful builds on this machine take about 8 hours.  Fail
builds~3-4 hours.  It's during stage2-bubble when compiling genrecog.c will
bail out, claiming no more virtual memory (2GB RAM + 3GB of swap).  So PR59461
clearly has some kind of issue on N32, with -march=mips3 or -march=r12000
(build machine is an SGI Octane w/ an R14000 CPU, so fairly old school).

The only other working MIPS machine I have is an SGI O2 with a rare RM7000 CPU.
 But gcc on that thing takes about 2-3 days for a successful build.  However,
it is running O32 ABI under uclibc-ng, so odds are likely gcc-7.x would compile
successfully.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

Joshua Kinard  changed:

   What|Removed |Added

Version|7.1.0   |7.2.0
Version|7.1.0   |7.2.0

--- Comment #4 from Joshua Kinard  ---
After a week of bisecting, it looks like PR59461 is what causes this
regression.  Indeed, looking at the comments on #59461, Matthew Fortune thought
that N64 could have been broken, and I am assuming that was fixed in PR78660? 
This issue I am seeing under N32 might be something different.

Here is the git bisect history I followed:

start:
bad da8dff89fa93 (HEAD)
good 45dd06cef49f (gcc-6_4_0-release)

 1. a050099a416f (good)
 2. 873a9b6435c7 (bad)
 3. eedf6f96c360 (good)
 4. 8139561f6fe6 (bad)
 5. c02417adbaf1 (good)
 6. 63c8aefc8cbf (bad)
 7. 48baf518aeb5 (skip)
 7. 36bb9d71a876 (good)
 8. 44618e466be5 (bad)
 9. 682d2b7ee96c (bad)
10. 4699a580bd1f (bad)
11. 15bd70ad1a73 (good)
12. 9dbb7881f36e (bad)
13. 454decdf75fc (bad)
14. 1998c023a3ed (bad)

Which then yields:

1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit
commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1
Author: ebotcazou 
Date:   Fri Nov 11 22:38:33 2016 +

PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS
is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is
not
larger than a word before invoking LOAD_EXTEND_OP on it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 dd706ac97469731dec045095572859552211457b
59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M  gcc



Note that part of the way through the bisect (~step 8), I had to manually apply
the patch from PR78338 to fix a build error.  The first attempt at step 7 also
had to be skipped one time due to another build error that I couldn't find much
on.

I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually
completes or not and report back.

Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.

--- Comment #5 from Joshua Kinard  ---
After a week of bisecting, it looks like PR59461 is what causes this
regression.  Indeed, looking at the comments on #59461, Matthew Fortune thought
that N64 could have been broken, and I am assuming that was fixed in PR78660? 
This issue I am seeing under N32 might be something different.

Here is the git bisect history I followed:

start:
bad da8dff89fa93 (HEAD)
good 45dd06cef49f (gcc-6_4_0-release)

 1. a050099a416f (good)
 2. 873a9b6435c7 (bad)
 3. eedf6f96c360 (good)
 4. 8139561f6fe6 (bad)
 5. c02417adbaf1 (good)
 6. 63c8aefc8cbf (bad)
 7. 48baf518aeb5 (skip)
 7. 36bb9d71a876 (good)
 8. 44618e466be5 (bad)
 9. 682d2b7ee96c (bad)
10. 4699a580bd1f (bad)
11. 15bd70ad1a73 (good)
12. 9dbb7881f36e (bad)
13. 454decdf75fc (bad)
14. 1998c023a3ed (bad)

Which then yields:

1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit
commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1
Author: ebotcazou 
Date:   Fri Nov 11 22:38:33 2016 +

PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS
is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is
not
larger than a word before invoking LOAD_EXTEND_OP on it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 dd706ac97469731dec045095572859552211457b
59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M  gcc



Note that part of the way through the bisect (~step 8), I had to manually apply
the patch from PR78338 to fix a build error.  The first attempt at step 7 also
had to be skipped one time due to another build error that I couldn't find much
on.

I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually
completes or not and report back.

Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

Joshua Kinard  changed:

   What|Removed |Added

Version|7.1.0   |7.2.0
Version|7.1.0   |7.2.0

--- Comment #4 from Joshua Kinard  ---
After a week of bisecting, it looks like PR59461 is what causes this
regression.  Indeed, looking at the comments on #59461, Matthew Fortune thought
that N64 could have been broken, and I am assuming that was fixed in PR78660? 
This issue I am seeing under N32 might be something different.

Here is the git bisect history I followed:

start:
bad da8dff89fa93 (HEAD)
good 45dd06cef49f (gcc-6_4_0-release)

 1. a050099a416f (good)
 2. 873a9b6435c7 (bad)
 3. eedf6f96c360 (good)
 4. 8139561f6fe6 (bad)
 5. c02417adbaf1 (good)
 6. 63c8aefc8cbf (bad)
 7. 48baf518aeb5 (skip)
 7. 36bb9d71a876 (good)
 8. 44618e466be5 (bad)
 9. 682d2b7ee96c (bad)
10. 4699a580bd1f (bad)
11. 15bd70ad1a73 (good)
12. 9dbb7881f36e (bad)
13. 454decdf75fc (bad)
14. 1998c023a3ed (bad)

Which then yields:

1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit
commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1
Author: ebotcazou 
Date:   Fri Nov 11 22:38:33 2016 +

PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS
is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is
not
larger than a word before invoking LOAD_EXTEND_OP on it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 dd706ac97469731dec045095572859552211457b
59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M  gcc



Note that part of the way through the bisect (~step 8), I had to manually apply
the patch from PR78338 to fix a build error.  The first attempt at step 7 also
had to be skipped one time due to another build error that I couldn't find much
on.

I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually
completes or not and report back.

Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.

--- Comment #5 from Joshua Kinard  ---
After a week of bisecting, it looks like PR59461 is what causes this
regression.  Indeed, looking at the comments on #59461, Matthew Fortune thought
that N64 could have been broken, and I am assuming that was fixed in PR78660? 
This issue I am seeing under N32 might be something different.

Here is the git bisect history I followed:

start:
bad da8dff89fa93 (HEAD)
good 45dd06cef49f (gcc-6_4_0-release)

 1. a050099a416f (good)
 2. 873a9b6435c7 (bad)
 3. eedf6f96c360 (good)
 4. 8139561f6fe6 (bad)
 5. c02417adbaf1 (good)
 6. 63c8aefc8cbf (bad)
 7. 48baf518aeb5 (skip)
 7. 36bb9d71a876 (good)
 8. 44618e466be5 (bad)
 9. 682d2b7ee96c (bad)
10. 4699a580bd1f (bad)
11. 15bd70ad1a73 (good)
12. 9dbb7881f36e (bad)
13. 454decdf75fc (bad)
14. 1998c023a3ed (bad)

Which then yields:

1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit
commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1
Author: ebotcazou 
Date:   Fri Nov 11 22:38:33 2016 +

PR rtl-optimization/59461
* doc/rtl.texi (paradoxical subregs): Add missing word.
* combine.c (reg_nonzero_bits_for_combine): Do not discard results
in modes with precision larger than that of last_set_mode.
* rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS
is
set and LOAD_EXTEND_OP is appropriate, propagate results from inner
REGs to paradoxical SUBREGs.
(num_sign_bit_copies1) : Likewise.  Check that the mode is
not
larger than a word before invoking LOAD_EXTEND_OP on it.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 dd706ac97469731dec045095572859552211457b
59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M  gcc



Note that part of the way through the bisect (~step 8), I had to manually apply
the patch from PR78338 to fix a build error.  The first attempt at step 7 also
had to be skipped one time due to another build error that I couldn't find much
on.

I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually
completes or not and report back.

Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #3 from Joshua Kinard  ---
It's just build/genrecog.c.  I had a stale build environment file that was
still sending "-j3" to 'make'.  I fixed that and restarted from where it last
left off, and it gets to genrecog.c and spent about ~20 minutes doing something
to that file before exhausting all virtual memory (so it claims).

Here's the last 'ps' output I got right before it stopped:
# ps uw 7054 | grep [g]enrecog
portage   7054 99.5 47.0 2056256 979712 pts/1  R+   09:36  20:57
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/cc1plus -quiet
-nostdinc++ -I . -I build -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/build -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../include -I
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/../libcpp/include
-iprefix
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-gcc/../../../lib/gcc/mips64-unknown-linux-gnu/7.1.0/
-isystem /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/include-fixed
-D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H -D GENERATOR_FILE -isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include/mips64-unknown-linux-gnu
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/prev-mips64-unknown-linux-gnu/libstdc++-v3/include
-isystem
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/libstdc++-v3/libsupc++
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/gcc/genrecog.c -meb
-quiet -dumpbase genrecog.c -march=mips3 -mtune=mips3 -mplt -mabi=n32 -mllsc
-mips3 -mno-shared -auxbase-strip build/genrecog.o -gtoggle -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format
-Woverloaded-virtual -Wpedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-fno-PIE -o -

This particular MIPS machine, an old Silicon Graphics platform, has memory
issues in the kernel (limited to 2GB of main memory because of what I think is
a hardware quirk I haven't figured out how to work around yet), but this is the
first time I've ever seen it run out of virtual memory compiling something in
the last 10 years.  It just recently completed gcc-6.3.0 across multiple ISAs
and ABIs about a week ago (it's a build machine), and also did gcc-7.1.0 in O32
under glibc and uclibc-ng.  So this is why I suspect there is something wrong
with the MIPS-III/N32 case.  I have not tried MIPS-IV yet (the machine only
supports the older four MIPS ISAs).  I do not have a bootstrapped N32 userland
under a different libc other than glibc.  I also lack a pure N64 userland to
test with as well.

The CPU is ~600MHz with 2MB of L2 cache, so I find that it spending 20+ minutes
on one C file to be rather abnormal, and I think there's a
runawaysomethinggoing on (linked list allocation or such?).

If there's something else I can grab with gdb or forcing a coredump, let me
know what commands to run.

[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

--- Comment #2 from Joshua Kinard  ---
(In reply to Richard Biener from comment #1)
> What file is it compiling?

As far as I can tell, it looks somewhat random.  I initially thought that
'build/genrecog.o' was a single file, but after several re-runs, I noticed
there's several files getting compiled that must get merged into genrecog.o.  I
was running a parallel build, too, though (only -j3, 2x SMP machine), so I
could have been seeing the other parallel thread(s) running.  I've restarted
the builod where it stopped using -j1.  It takes about an hour to get back to
where it will stop.  I'll report what that file is, and then launch it again
and see if it stays consistent.

[Bug middle-end/81443] New: gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

[kumba at gentoo dot org]

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

Bug ID: 81443
   Summary: gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory
exhausted: Cannot allocate memory
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kumba at gentoo dot org
  Target Milestone: ---

I am attempting to compile gcc-7.1.0 on a 64-bit MIPS platform, targeting the
MIPS-III ISA, glibc-userland, N32 ABI, big-endian architecture, and an unable
to complete the compile due to exhausting all available virtual memory.  The
machine in question has 2GB of physical RAM installed and ~7GB of swap space
(3GB in partitions, 4GB as a temp swap file).  I at first thought it was the
parallelization (-j3 to make), since the machine is dual CPU, but it also fails
as -j2 and -j1.  I watched the swap usage with 'watch -n2 swapon --show', and
when the compile terminates, swap is barely at 50%, so I don't think it's
related to lack of available swap space.

I was able to successfully compile gcc-7.1 on the same machine, different
chroot, under the O32 ABI for glibc-2.24, and O32 ABI for uclibc-ng-1.0.25 in
another chroot.  So I suspect this is a regression for the N32 ABI case.

I am not sure what files or data will of use to run this one down.  I am
preserving the last builddir for now, so if specific files are needed for
analysis, let me know.

# /var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/xg++ -v
Using built-in specs.
COLLECT_GCC=/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/build/./prev-gcc/xg++
Target: mips64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-7.1.0-r1/work/gcc-7.1.0/configure
--host=mips64-unknown-linux-gnu --build=mips64-unknown-linux-gnu --prefix=/usr
--bindir=/usr/mips64-unknown-linux-gnu/gcc-bin/7.1.0
--includedir=/usr/lib/gcc/mips64-unknown-linux-gnu/7.1.0/include
--datadir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0
--mandir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/man
--infodir=/usr/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/mips64-unknown-linux-gnu/7.1.0/include/g++-v7
--with-python-dir=/share/gcc-data/mips64-unknown-linux-gnu/7.1.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 7.1.0-r1 p1.1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point
--with-abi=n32 --disable-libgcj --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libcilkrts --disable-libmpx --disable-vtable-verify
--disable-libvtv --disable-libquadmath --enable-lto --without-isl
--disable-libsanitizer --disable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.0 (Gentoo 7.1.0-r1 p1.1)

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #41 from Joshua Kinard  ---
(In reply to Andrew Pinski from comment #38)
> Does this work now?

Whatever the issue on MIPS/N32 was, it's resolved by dropping -Wl,-z,now.  So
no longer an issue AFAICT.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #36 from Joshua Kinard  ---
(In reply to Joshua Kinard from comment #35)
> 
> It looks like it's my LDFLAGS, specifically with -Wl,-z,now.

It looks like this might be a problem with my toolchain, possibly in binutils,
and possibly only for MIPS N32.  I discovered another program that was having
odd issues, and on a whim, re-compiled it without using -Wl,-z,now, and it
started to work correctly again.  Going to downgrade binutils a few times and
see if there's a specific version that stands out as causing the problem.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #35 from Joshua Kinard  ---
(In reply to rguent...@suse.de from comment #34)
> On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> > 
> > --- Comment #33 from Joshua Kinard  ---
> > The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
> > (Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from 
> > building,
> > and it ended up completing.  Difference between that script (which builds
> > inside a chroot) is I used saner CFLAGS.
> > 
> > The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
> > CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
> > -fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
> > LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"
> > 
> > So I'll look at dropping one flag at a time, along with trimming LDFLAGS, 
> > and
> > see if I can pin down which one causes ./genmatch --gimple to segfault 
> on N32.
> 
> -fforce-addr is a no-op and -fivopts is enabled at -O2 by default, so
> you can omit those without testing.

It looks like it's my LDFLAGS, specifically with -Wl,-z,now.  I let the build
proceed after removing LDFLAGS from my environment, and once it built genmatch
and ran it w/o a SIGSEGV, I interrupted the build, copied the linking command
for genmatch, and then tested with both -Wl,-z,now and -Wl,-z,relro, and the
relro version runs fine.

# mips64-unknown-linux-gnu-g++ -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,now -o
build/genmatchZ3 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ3 --gimple
Segmentation fault


# mips64-unknown-linux-gnu-g++ -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-z,relro
-o build/genmatchZ4 build/genmatch.o
../build-mips64-unknown-linux-gnu/libcpp/libcpp.a build/errors.o build/vec.o
build/hash-table.o ../build-mips64-unknown-linux-gnu/libiberty/libiberty.a

# build/genmatchZ4 --gimple
(null):0:0 error: --gimple: No such file or directory


Currently using binutils-2.25.1.  Can provide strace runs if needed.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #33 from Joshua Kinard  ---
The problem may be tied to a particular CFLAG on glibc-n32 MIPS.  I ran our
(Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from building,
and it ended up completing.  Difference between that script (which builds
inside a chroot) is I used saner CFLAGS.

The CFLAGS I am using in my rootfs that fails to build gcc-5.3.0 is:
CFLAGS="-O2 -pipe -march=r12k -mtune=r12k -mno-fix-r1 -mabi=n32 -mplt
-fomit-frame-pointer -fforce-addr -fivopts -fmodulo-sched -ftree-vectorize"
LDFLAGS="-Wl,-O2 -Wl,-z,now -Wl,-z,relro"

So I'll look at dropping one flag at a time, along with trimming LDFLAGS, and
see if I can pin down which one causes ./genmatch --gimple to segfault on N32.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #32 from Joshua Kinard  ---
(In reply to Richard Biener from comment #30)
> Any status update?  Does bootstrap work on trunk (with --disable-checking)?

Okay, here's updates from the MIPS angle on a few configurations:

MIPS-IV, Big-endian, N32, glibc (mips64-unknown-linux-gnu):
Still fails with either --disable-checking or --enable-checking=release.  Same
problem as before:

build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd \
> tmp-gimple-match.c
/bin/bash: line 1: 16563 Segmentation fault  build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/match.pd >
tmp-gimple-match.c
Makefile:2325: recipe for target 's-match' failed
make[3]: *** [s-match] Error 139
make[3]: *** Waiting for unfinished jobs

Can't test O32/glibc at present due to accidentally mangling my old O32 rootfs.
 Might get something up and working again at some point, but I *highly* suspect
the problem only exists in N32 (unknown about N64).  See below for why.

---

MIPS-IV, Big-endian, O32, uclibc (mips-unknown-linux-uclibc):
--disable-checking appears to produce an ICE in an O32/uclibc rootfs.  I assume
you'll want a fresh bug opened on this:
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/../libcpp/include  \
-o build/genoutput.o
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genoutput.c
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c: In
function 'void form_regexp(regexp_t)':
/usr/obj/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/gcc/genautomata.c:6867:1:
internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2318
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:2451: recipe for target 'build/genautomata.o' failed
make[3]: *** [build/genautomata.o] Error 1
make[3]: *** Waiting for unfinished jobs

I'll have to re-create the above scenario to do so, as I'm running a few
different experiments w/ uclibc at the moment, so I need to make sure it really
is --disable-checking causing the problem there and I'll run the bug through
our (Gentoo's) toolchain team first before opening a PR here.

---

Now, same O32/uclibc rootfs, --enable-checking=release, gcc-5.3.0 works fine
(so far).  This is why I suspect the N32 case is broken only.  I don't know how
good N32 support in uclibc is, so I can't test that configuration to verify.

So to tackle the N32 issue, are there any additional tricks you want me to try
to get, say, a static copy of genmatch built w/ debugging symbols and then step
through it in GDB to see what may be triggering the segfault?  I didn't try
removing the 'gcc_checking_assert', as suggested in earlier comments.

N32 does affect the reported size of several datatypes, so that may be the
source of the issue on MIPS.

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #27 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Richard Biener from comment #26)
 Don't hold your breath.  Basically somebody who can reproduce it has to find
 the root-cause and a fix.

4.9.3 works, and the problem appears specific to genmatch with the '--gimple'
argument.  I guess I can test to see if 5.0.0 is also affected, and then start
diffing the genmatch.c files between working/non-working version to trace the
problem down.  That will be quicker than git bisecting on these machines (old
SGI machines).  Can't stay stuck on 4.9.x forever...

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

--- Comment #25 from Joshua Kinard kumba at gentoo dot org ---
Still present in gcc-5.2.  Reverting commit r218976 also didn't help. 
Reproduced on a second MIPS machine running N32 ABI as well.  any idea if this
is being looked at for 5.3?

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]

[kumba at gentoo dot org]

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

Joshua Kinard kumba at gentoo dot org changed:

   What|Removed |Added

 CC||kumba at gentoo dot org

--- Comment #23 from Joshua Kinard kumba at gentoo dot org ---
I ran into this on a Linux/mips64 (MIPS-IV ISA) build as well, running N32 ABI.

mips64-unknown-linux-gnu-g++ -c  -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/build
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../include 
-I/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/../libcpp/include  \
-o build/gcov-iov.o
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/gcov-iov.c
build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd \
 tmp-gimple-match.c
/bin/bash: line 1:   835 Segmentation fault  build/genmatch --gimple
/usr/obj/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/gcc/match.pd 
tmp-gimple-match.c
Makefile:2318: recipe for target 's-match' failed
make[3]: *** [s-match] Error 139
make[3]: *** Waiting for unfinished jobs

This is in the 'all-stage1-gcc' stage from 'stage1-bubble'.  I did not see any
'ld' warnings prior to that, but I have this in dmesg:

[47163.043326]
   do_page_fault(): sending SIGSEGV to genmatch for invalid read
access from 
[47163.043354] epc =  in
[47163.043402]  genmatch[1000+9]
[47163.043412] ra  = 1000b960 in
[47163.043436]  genmatch[1000+9]

Running a 64KB PAGE_SIZE, too, if that matters.  I'll try to reverse commit
r218976 from Comment #11 to see if that resolves the issue for me as well and
update later.

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

[kumba at gentoo dot org]

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

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

[kumba at gentoo dot org]

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

Joshua Kinard kumba at gentoo dot org 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 kumba at gentoo dot org ---
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

[kumba at gentoo 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.

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

[kumba at gentoo dot org]

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

--- Comment #17 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Joshua Kinard from comment #16)
 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.

Already mentioned to Andrew on IRC, but reversing these four commits solves the
problem, but I am still not sure why it affects R1x000 CPUs.  I can upload the
static binaries of 'sln' for someone to look at if they'd like.

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

[kumba at gentoo dot org]

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

Joshua Kinard kumba at gentoo dot org 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 kumba at gentoo dot org ---
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

[kumba at gentoo dot org]

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

--- Comment #19 from Joshua Kinard kumba at gentoo dot org ---
Created attachment 33165
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33165action=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

[kumba at gentoo dot org]

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

--- Comment #20 from Joshua Kinard kumba at gentoo dot org ---
Created attachment 33166
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33166action=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.

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

[kumba at gentoo 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.

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

[kumba at gentoo dot org]

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

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

So far, I am leaning towards commit 30c3c4427521f96fb58b6e1debb86da4f113f06f as
the culprit.  That was added on June 20th, and I *think* the refactoring of the
case statement is wrong for MIPS.  The logic just doesn't seem to work out to
be the same as the old code it replaced, and maybe this only is a problem on
the R1 processors.  So if my build for June 19 2012 works, then a another
'git bisect good' should put me somewhere between the 23rd/24th, and if that's
bad, I'm going to then try to test a gcc checkout both with and without that
one commit to verify if it's the bug or not.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=30c3c4427521f96fb58b6e1debb86da4f113f06f

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

[kumba at gentoo dot org]

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

--- Comment #12 from Joshua Kinard kumba at gentoo dot org ---
So I discovered the presence of the --disable-linux-futex configure flag,
rebuilt gcc-4.9.0 with it, and tested my conftest.c testcase, and can confirm
that the resulting binary no longer hangs on a futex syscall.  It still calls
futex twice somewhere in the call chain, but that's probably expected behavior
or a different library (pthreads?):

set_tid_address(0x77256068) = 10805
set_robust_list(0x77256070, 12) = 0
futex(0x7fcb46b8, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fcb46b8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) =
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205b94}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {0x1008, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205a34}, NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0
futex(0x771fb9a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x771fb9a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
exit_group(0)   = ?
+++ exited with 0 +++

So, not the ideal solution, as I assume under a Linux kernel, there is some
advantage to using the futex syscall within gcc, but I don't know how that will
affect things.  I'll try to compile glibc-2.19 with gcc-4.9.0 and see if the
'sln' static binary also hangs with this change.

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

[kumba at gentoo dot org]

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

--- Comment #10 from Joshua Kinard kumba at gentoo dot org ---
I rebuilt both glibc-2.19 and gcc-4.8.3 w/ debugging, though gcc's build system
managed to strip out or optimize away some of the debugging code.  That said,
it's enough to see that the hang is being triggered by gcc because it makes two
futex syscalls in gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290:
syscall (SYS_futex, gi, _GLIBCXX_FUTEX_WAIT, expected, 0);

The first one lines up with the strace output where it gets -1 EAGAIN, and then
the second attempt is where the program hangs.

From GDB:
(gdb) r
Starting program: /usr/obj/mips-unknown-linux-gnu/c2
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/libthread_db.so.1.

Catchpoint 1 (call to syscall 4238), __pthread_initialize_minimal_internal ()
at nptl-init.c:328
(gdb) c
Continuing.

Catchpoint 1 (call to syscall 4238), 0x77f9dd90 in
__pthread_initialize_minimal_internal () at nptl-init.c:348
(gdb) break *0x77d2b684
Breakpoint 2 at 0x77d2b684: file ../sysdeps/unix/syscall.S, line 27.
(gdb) break *0x77ec621c
Breakpoint 3 at 0x77ec621c: file
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc,
line 290.
(gdb) c
Continuing.

Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
guard variable for (anonymous
namespace)::__future_category_instance()::__fec)
at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.

Breakpoint 2, 0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb) c
Continuing.

Breakpoint 3, 0x77ec621c in __cxxabiv1::__cxa_guard_acquire (g=0x77f95500
guard variable for (anonymous
namespace)::__future_category_instance()::__fec)
at
/usr/obj/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/libstdc++-v3/libsupc++/guard.cc:290
(gdb) c
Continuing.
HANGS HERE
^C
Program received signal SIGINT, Interrupt.
0x77d2b684 in syscall () at ../sysdeps/unix/syscall.S:27
(gdb)

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

[kumba at gentoo dot org]

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

--- Comment #11 from Joshua Kinard kumba at gentoo dot org ---
I also have another test case from glibc itself, where when compiling
glibc-2.19 w/ gcc-4.8.x or greater, at the end, it creates a statically-linked
version of 'ln' as 'sln', and tries to run that.  That binary also hangs, but
it hangs in glibc-specific code:

nptl/sysdeps/unix/sysv/linux/lowlevellock.c:
  ¦32while (atomic_exchange_acq (futex, 2) != 0)
   ¦33  lll_futex_wait (futex, 2, LLL_PRIVATE);
   ¦34  }

Which looks like it's hanging in lll_futex_wait().  If I set a breakpoint on
that address in the asm layout, I can see this:

Breakpoint 1, 0x00423bf4 in __lll_lock_wait_private (futex=0x4a215c
_IO_stdfile_1_lock) at ../nptl/sysdeps/unix/sysv/linux/lowlevellock.c:33
   ¦0x423be0 __lll_lock_wait_private+32   0x7c03e83b
   ¦0x423be4 __lll_lock_wait_private+36   li a2,2
   ¦0x423be8 __lll_lock_wait_private+40   lw a1,-29832(v1)
   ¦0x423bec __lll_lock_wait_private+44   move   a3,zero
   ¦0x423bf0 __lll_lock_wait_private+48   li v0,4238
B+¦0x423bf4 __lll_lock_wait_private+52   syscall

(gdb) x/6i 0x4a215c
   0x4a215c _IO_stdfile_1_lock:   srl zero,zero,0x0
   0x4a2160 _IO_stdfile_1_lock+4: nop
   0x4a2164 _IO_stdfile_1_lock+8: nop
   0x4a2168 _IO_stdfile_0_lock:   nop
   0x4a216c _IO_stdfile_0_lock+4: nop
   0x4a2170 _IO_stdfile_0_lock+8: nop

I did find two very recent patches on libc-alpha that deal specifically with
lowlevellock.h, by replacing it (and all other arch-specific variants) with a
generic lowlevellock.h file:
https://sourceware.org/ml/libc-alpha/2014-06/msg00174.html
https://sourceware.org/ml/libc-alpha/2014-06/msg00419.html

And this interesting comment:
https://sourceware.org/ml/libc-alpha/2014-06/msg00184.html

I am going to try rebuilding glibc with those and see if I am still getting
hangs or not.

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

[kumba at gentoo dot org]

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

--- Comment #9 from Joshua Kinard kumba at gentoo dot org ---
Rebuilt/upgraded to gcc-4.8.3 against the patched glibc-2.19, and I am still
getting the hang.

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

[kumba at gentoo dot org]

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

--- Comment #3 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Jonathan Wakely from comment #2)
 Can you provide a stack trace to show which constructor/destructor it's
 hanging in?

Hopefully you mean a backtrace from gdb.  Not finding a lot of info on doing a
C++ stacktrace (I haven't messed with C++ in years).

The testcase isn't stripped and has debugging info, but glibc-2.19, and
gcc-4.8.2 are stripped and built w/o debugging, so the backtrace doesn't
provide a lot of info.  I might be able to rebuild them w/ debugging, but gcc
takes almost 13+ hours on the Octane to build, while glibc takes another 3-4.

First, here is what strace shows:
set_tid_address(0x7797f2e8) = 2532
set_robust_list(0x7797f2f0, 12) = 0
futex(0x7fb06690, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fb06690, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) =
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_NOCLDWAIT|0x7921a94}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {0x1008, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|SA_NOCLDWAIT|0x7921940}, NULL,
16) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0
syscall(0x108e, 0x77929500, 0, 0, 0, 0, 0x77929160) = -1 EAGAIN (Resource
temporarily unavailable)
syscall(0x108e, 0x77929500, 0, 0x10100, 0, 0, 0x77929160

That last line is where you see it hanging until I send ctrl+c, with the first
argument to both being 0x108e (4238 in decimal, I typoed it as '4328' in my
original post), which is a futex call, per mips-o32-linux.xml in GDB:
  syscall name=futex number=4238/

Running in GDB, setting a catchpoint on syscall 4238 and upping the
heuristic-fence-post limit a fair bit to quiet some warnings down:

This first catchpoint doesn't hang:
 ¦0x77f9dc1c __pthread_initialize_minimal_internal+148  addiu  a0,s8,32
 ¦0x77f9dc20 __pthread_initialize_minimal_internal+152  li a1,129
 ¦0x77f9dc24 __pthread_initialize_minimal_internal+156  li a2,1
 ¦0x77f9dc28 __pthread_initialize_minimal_internal+160  li v0,4238
 ¦0x77f9dc2c __pthread_initialize_minimal_internal+164  syscall
¦0x77f9dc30 __pthread_initialize_minimal_internal+168  bnez   a3,0x77f9df9c 
__pthread_initialize_minimal_internal+1044

Catchpoint 1 (call to syscall 4238), 0x77f9dc30 in
__pthread_initialize_minimal_internal () from /lib/libpthread.so.0
(gdb) thread apply all bt

Thread 1 (process 2584):
#0  0x77f9dc30 in __pthread_initialize_minimal_internal () from
/lib/libpthread.so.0
#1  0x77f9c5a4 in _init () from /lib/libpthread.so.0
Cannot access memory at address 0x77fc3ffe

Here's the second catchpoint for syscall #4238:
 ¦0x77f9dc64 __pthread_initialize_minimal_internal+220  addiu  sp,sp,-32
 ¦0x77f9dc68 __pthread_initialize_minimal_internal+224  sw v0,16(sp)
 ¦0x77f9dc6c __pthread_initialize_minimal_internal+228  li v0,4238
 ¦0x77f9dc70 __pthread_initialize_minimal_internal+232  syscall
¦0x77f9dc74 __pthread_initialize_minimal_internal+236  addiu  sp,sp,32

Catchpoint 1 (call to syscall 4238), 0x77f9dc74 in
__pthread_initialize_minimal_internal () from /lib/libpthread.so.0
(gdb) thread apply all bt

Thread 1 (process 2584):
#0  0x77f9dc74 in __pthread_initialize_minimal_internal () from
/lib/libpthread.so.0
#1  0x77f9c5a4 in _init () from /lib/libpthread.so.0
Cannot access memory at address 0x77fc3ffe

After I type continue again, it hangs until interrupted:
(gdb) c
Continuing.
HANGS HERE

Program received signal SIGINT, Interrupt.
0x77d50864 in syscall () from /lib/libc.so.6
(gdb) thread apply all bt

Thread 1 (Thread 0x77feb000 (LWP 2591)):
#0  0x77d50864 in syscall () from /lib/libc.so.6
#1  0x77ed9160 in __cxa_guard_acquire () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
#2  0x77f4325c in std::future_category() () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
#3  0x77ed406c in ?? () from
/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
Cannot access memory at address 0x77fc3ffe
(gdb)

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

[kumba at gentoo dot org]

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

--- Comment #4 from Joshua Kinard kumba at gentoo dot org ---
It looks like the bug might be somewhere in __cxa_guard_acquire() in
libstdc++-v3/lubsupc++/guard.cc, as that references glibc and futexes.  strace
indicates that the same syscall was invoked twice in a row -- could this be a
double-locking bug?

This is what I traced out in gdb:

   ¦0x77ed91cc __cxa_guard_acquire+336sw zero,32(sp)
B+¦0x77ed91d0 __cxa_guard_acquire+340b  0x77ed9144
__cxa_guard_acquire+200
|
|-¦0x77ed9144 __cxa_guard_acquire+200lw t9,-28620(gp)
   ¦0x77ed9148 __cxa_guard_acquire+204li a0,4238
   ¦0x77ed914c __cxa_guard_acquire+208move   a1,s0
   ¦0x77ed9150 __cxa_guard_acquire+212move   a2,zero
   ¦0x77ed9154 __cxa_guard_acquire+216lw a3,32(sp)
   ¦0x77ed9158 __cxa_guard_acquire+220jalr   t9
|
|-¦0x77d50850 syscallluigp,0x9
   ¦0x77d50854 syscall+4  addiu  gp,gp,-2624
   ¦0x77d50858 syscall+8  addu   gp,gp,t9
   ¦0x77d5085c syscall+12 li v0,4000
   ¦0x77d50860 syscall+16 syscall
   HANGS HERE
   ¦0x77d50864 syscall+20 bnez   a3,0x77d50840
   ¦0x77d50868 syscall+24 nop
   ¦0x77d5086c syscall+28 jr ra
   ¦0x77d50870 syscall+32 nop
   ¦0x77d50874 syscall+36 nop
   ¦0x77d50878  nop
   ¦0x77d5087c  nop

I can see the first futex syscall (li a0,4238), and I think it looks like
inside that syscall, it's doing some loads and adds, then makes a generic
syscall (#4000), probably passing the computed 0x108e value as the first
argument, which would translate into another futex syscall, which jives with
what strace says.  Is taking a futex inside of a futex a good thing?  It's
obvious that something with the R1x000 CPU is coming into play as well, but I
don't know what exactly.

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

[kumba at gentoo dot org]

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

--- Comment #7 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Andrew Pinski from comment #6)
 This is the patch which I used for glibc to fix some libstdc++ issues:

Okay, so it's in glibc.  Is your patch in glibc yet?  It applies cleanly to
2.19, but carries a 2012 date stamp.  I'll rebuild and see if this solves the
bug.  Thanks!

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

[kumba at gentoo dot org]

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

--- Comment #8 from Joshua Kinard kumba at gentoo dot org ---
(In reply to Joshua Kinard from comment #7)
 (In reply to Andrew Pinski from comment #6)
  This is the patch which I used for glibc to fix some libstdc++ issues:
 
 Okay, so it's in glibc.  Is your patch in glibc yet?  It applies cleanly to
 2.19, but carries a 2012 date stamp.  I'll rebuild and see if this solves
 the bug.  Thanks!

Still hangs on the second syscall.  I can trace the asm and see where it's
taking a different route due to those atomic_full_barrier() calls, but I'll
have to rebuild gcc next just to be completely sure.

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

[kumba at gentoo dot org]

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

Bug ID: 61538
   Summary: g++ compiled binary, linked to glibc libpthread, hangs
on SGI MIPS R1x000 systems on Linux
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kumba at gentoo dot org
CC: toolchain at gentoo dot org
  Host: mips-unknown-linux-gnu
Target: mips-unknown-linux-gnu
 Build: mips-unknown-linux-gnu

I appear to have run into a regression in g++/libstdc++, starting with at least
4.8.2, where a simple binary built by g++ and linked to glibc-2.19's libpthread
causes the binary to hang on a kernel futex() syscall (syscall #4328 in o32
ABI) until killed or interrupted w/ ctrl-C.

I have replicated this problem in an o32 environment, as well as an n32 and n64
multilib environment.

So far, the identified trigger conditions are:
- Must be an R1-based SGI system (SGI O2 w/ RM7000 does not reproduce)
- Must compile testcase w/ 'g++' (compiling with 'gcc' works fine)
- Must link w/ -lpthread from at least glibc-2.19 (doesn't seem to trigger on
older versions).
- Must be gcc-4.8.2 or greater (gcc-4.6.4 and gcc-4.7.3 both work fine).

I ran into this while getting Linux support for the SGI Octane operational
again and rebuilding a ~5-year old Gentoo userland on the machine.  I at first
thought it was a problem with old libs still living on the system that I
haven't purged just yet, but I have been able to recreate the problem in a
clean n32/n64 Gentoo stage3 chroot.

The Octane in particular has an R14000 CPU module installed right now, though I
can also trigger the condition on an R12000 CPU module as well.  I don't have
any other working R1x000-capable SGI hardware available at the moment to test
this on, so this could still be a quirky bug in the Octane's kernel, but I
believe this is less likely since I can trigger the problem only with specific
versions of libstdc++.

Sample C code that I can use to trigger the issue with from Python-3.3.5's
configure script (where it etsts for thread support):
# cat conftest.c
void foo();int main(){foo();}void foo(){}

Compiler command line:
# g++ -o conftest conftest.c -lpthread

# ./conftest
hang

Overriding LD_PRELOAD to use libstdc++ from an earlier gcc:

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/libstdc++.so.6
./conftest
hang

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.8.2/libstdc++.so.6
./conftest
hang

# LD_PRELOAD=/usr/lib/gcc/mips-unknown-linux-gnu/4.7.3/libstdc++.so.6
./conftest
returns

I don't have much more than that at the moment, but let me know if there are
specific command outputs needed to further determine what the cause of this
problem is.

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

[kumba at gentoo dot org]

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

--- Comment #1 from Joshua Kinard kumba at gentoo dot org ---
Forgot the gcc -v info:
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/mips-unknown-linux-gnu/gcc-bin/4.9.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips-unknown-linux-gnu/4.9.0/lto-wrapper
Target: mips-unknown-linux-gnu
Configured with: /usr/obj/portage/sys-devel/gcc-4.9.0/work/gcc-4.9.0/configure
--host=mips-unknown-linux-gnu --build=mips-unknown-linux-gnu --prefix=/usr
--bindir=/usr/mips-unknown-linux-gnu/gcc-bin/4.9.0
--includedir=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/include
--datadir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0
--mandir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0/man
--infodir=/usr/share/gcc-data/mips-unknown-linux-gnu/4.9.0/info
--with-gxx-include-dir=/usr/lib/gcc/mips-unknown-linux-gnu/4.9.0/include/g++-v4
--with-python-dir=/share/gcc-data/mips-unknown-linux-gnu/4.9.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.9.0 p1.0, pie-0.6.0' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point
--with-abi= --disable-libgcj --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libquadmath --enable-lto --without-cloog
Thread model: posix
gcc version 4.9.0 (Gentoo 4.9.0 p1.0, pie-0.6.0)

[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled

[kumba at gentoo dot org]

--- Comment #2 from kumba at gentoo dot org  2008-11-12 01:01 ---
I ran into this too.  The problem flag is -foptimize-sibling-calls.  You can
pass that with -O1 to trigger the bug, but not with -O0.  Some other
optimization in -O1 seems to be mixing with this one and causing the flaw.

Ran into this on mips-unknown-linux-gnu, btw.  Mips-specific maybe?


-- 

kumba at gentoo dot org changed:

   What|Removed |Added

 CC||kumba at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052

[Bug other/36969] MIPS: gcc-4.3.1 still fails to compile glibc w/ PR/35802 applied

[kumba at gentoo dot org]

--- Comment #3 from kumba at gentoo dot org  2008-10-25 16:58 ---
The patch did work, but I've since moved onto using 4.3.2, which has no
problems.  Closing as WORKSFORME


-- 

kumba at gentoo dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969

[Bug other/36969] MIPS: gcc-4.3.1 still fails to compile glibc w/ PR/35802 applied

[kumba at gentoo dot org]

--- Comment #2 from kumba at gentoo dot org  2008-07-31 01:21 ---
My apologies!  I searched in several areas (google, gcc ML, gcc-bugs, etc..),
and nothing turned up at first, so I thought I'd log a bug.  Bit behind and
playing catch up on a number of things.

I'll test the linked patch and close this if it works.  Thanks!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969

[Bug other/36969] New: MIPS: gcc-4.3.1 still fails to compile glibc w/ PR/35802 applied

[kumba at gentoo dot org]

gcc-4.3.1 seems to have a tough time building glibc as far as I can tell.  We
initially had problems due to the issue described in Bug #35802.  After that
was fixed, I tested that patch (pieced together from CVS) against 4.3.1, and
attempted glibc again, and now I'm getting a different error that I can't find
any pointers on what the cause may be.  Figured I'd start here to figure out
whether the problem is in gcc, glibc, or some patch we (Gentoo) are applying
(or not applying).

Here's the last line of compile, including error:

mips-unknown-linux-gnu-gcc -mabi=32 ../ports/sysdeps/mips/libc-tls.c -c
-std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings
-fmerge-all-constants -fno-strict-aliasing -march=r1 -mtune=r1 -pipe
-Wstrict-prototypes  -I../include
-I/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu
-I/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl
-I../ports/sysdeps/mips/elf -I../ports/sysdeps/unix/sysv/linux/mips/mips32
-I../ports/sysdeps/unix/sysv/linux/mips/nptl
-I../ports/sysdeps/unix/sysv/linux/mips -I../nptl/sysdeps/unix/sysv/linux
-I../nptl/sysdeps/pthread -I../sysdeps/pthread
-I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman
-I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv
-I../sysdeps/unix/sysv -I../ports/sysdeps/unix/mips/mips32
-I../ports/sysdeps/unix/mips -I../nptl/sysdeps/unix -I../ports/sysdeps/unix
-I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/mips/mips32
-I../ports/sysdeps/mips -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/wordsize-32 -I../ports/sysdeps/mips/fpu
-I../ports/sysdeps/mips/nptl -I../sysdeps/ieee754 -I../sysdeps/generic/elf
-I../sysdeps/generic -I../nptl -I../ports  -I.. -I../libio -I. -nostdinc
-isystem /usr/lib/gcc/mips-unknown-linux-gnu/4.3.1/include -isystem
/usr/lib/gcc/mips-unknown-linux-gnu/4.3.1/include-fixed -isystem /usr/include
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC 
-DHAVE_INITFINI -o
/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu/libc-tls.o
-MD -MP -MF
/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu/libc-tls.o.dt
-MT
/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu/libc-tls.o
libc-start.c: In function '__libc_start_main':
libc-start.c:216: error: impossible constraint in 'asm'
make[2]: ***
[/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu/libc-start.o]
Error 1
make[2]: *** Waiting for unfinished jobs
../ports/sysdeps/mips/libc-tls.c: In function '__tls_get_addr':
../ports/sysdeps/mips/libc-tls.c:33: error: impossible constraint in 'asm'
make[2]: ***
[/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/build-default-mips-unknown-linux-gnu-nptl/csu/libc-tls.o]
Error 1
make[2]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/glibc-2.8-20080602/csu'
make[1]: *** [csu/subdir_lib] Error 2
make[1]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.8_p20080602/work/glibc-2.8-20080602'
make: *** [all] Error 2

If any more information is needed, please let me know.  Thanks!


-- 
   Summary: MIPS: gcc-4.3.1 still fails to compile glibc w/ PR/35802
applied
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
 GCC build triplet: mips-linux-gnu
  GCC host triplet: mips-linux-gnu
GCC target triplet: mips-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969

[Bug target/35802] MIPS64: Unable to find a register to spill in class #8216;V1_REG#8217;

[kumba at gentoo dot org]

--- Comment #4 from kumba at gentoo dot org  2008-04-21 02:13 ---
Just ran into this myself, with the following error on glibc-2.7, building with
gcc-4.3.0, but on a different file:

plural-exp.c: In function '__gettext_extract_plural':
plural-exp.c:157: error: unable to find a register to spill in class 'V1_REG'
plural-exp.c:157: error: this is the insn:
(insn 80 151 161 6 ../include/ctype.h:33 (set (reg:SI 5 $5 [272])
(unspec:SI [
(const_int 0 [0x0])
] 28)) 460 {tls_get_tp_si} (expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0x0])
] 28)
(nil)))
plural-exp.c:157: confused by earlier errors, bailing out
make[2]: ***
[/usr/obj/portage/sys-libs/glibc-2.7-r2/work/build-default-mips-unknown-linux-gnu-nptl/intl/plural-exp.o]
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.7-r2/work/glibc-2.7/intl'
make[1]: *** [intl/subdir_lib] Error 2
make[1]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.7-r2/work/glibc-2.7'
make: *** [all] Error 2

Ideas to try?  Maybe a patch already in trunk to test?


-- 

kumba at gentoo dot org changed:

   What|Removed |Added

 CC||kumba at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35802

[Bug regression/25871] New: TRAMPOLINE_TEMPLATE uses 32bit moves on 64bit code

[kumba at gentoo dot org]

In gcc/config/mips/mips.h, the TRAMPOLINE_TEMPLATE macro uses three 32bit move
statements, that when working with 64bit code, will cause problems.  The only
time this has been observed thus far was in filesystem code borrowed from grub
which relied heavily on nested functions.

A patch against trunk is attached, but this bug goes as far back as 3.3.x.


-- 
   Summary: TRAMPOLINE_TEMPLATE uses 32bit moves on 64bit code
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871

[Bug regression/25871] TRAMPOLINE_TEMPLATE uses 32bit moves on 64bit code

[kumba at gentoo dot org]

--- Comment #1 from kumba at gentoo dot org  2006-01-20 06:48 ---
Created an attachment (id=10683)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10683action=view)
Use dmove/move where appropriate


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871

[Bug regression/25871] TRAMPOLINE_TEMPLATE uses 32bit moves on 64bit code

[kumba at gentoo dot org]

--- Comment #2 from kumba at gentoo dot org  2006-01-20 06:54 ---
Created an attachment (id=10684)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10684action=view)
Use dmove/move where appropriate

Typo in original, this is the correct version.


-- 

kumba at gentoo dot org changed:

   What|Removed |Added

  Attachment #10683|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871

[Bug middle-end/25437] New: gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

On two different architectures for Linux, gcc-4.0.2 appears to produce bad code
when compiling the RC5 crypto test (crypto/rc5 in openssl) when using any level
of optimization.  Compiling the testcase with -O1, -O2, or -O3 will trigger the
bug.  -O0 allows the test to complete successfully.  This is verified on 0.9.7i
and 0.9.8a on Linux/Mips and Linux/S390.  Linux/PPC32, Linux/x86_64,
Linux/i386, and Linux/IA64 appear to be unaffected.  Linux/Sparc, Arm, sh and
others were not tested.

The primary testing system/environment was an SGI Octane running a 64bit Linux
kernel on a 32bit userland environment, glibc-2.3.6, binutils-2.16.91.0.2.

There already exists a bug in OpenSSL's bugs database regarding the issue:
http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1203
(May want a login, use the guest login).

The attached testcase is a trimmed-down version of OpenSSL's RC5 test code used
in the test phase of the build.


-- 
   Summary: gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5
Crypto Test
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
 GCC build triplet: mips-unknown-linux-gnu
  GCC host triplet: mips-unknown-linux-gnu
GCC target triplet: mips-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #1 from kumba at gentoo dot org  2005-12-16 00:42 ---
Created an attachment (id=10506)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10506action=view)
Expected Results


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #2 from kumba at gentoo dot org  2005-12-16 00:42 ---
Created an attachment (id=10507)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10507action=view)
What Really Happens


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #3 from kumba at gentoo dot org  2005-12-16 00:44 ---
Created an attachment (id=10508)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10508action=view)
Testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #4 from kumba at gentoo dot org  2005-12-16 00:47 ---
Forgot to add, the failure itself was traceable to the RC5_32_set_key()
function in rc5_skey.c in the original files.  In the attached testcase, the
function in question begins on Line #554.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #5 from kumba at gentoo dot org  2005-12-16 00:50 ---
Created an attachment (id=10509)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10509action=view)
Preprocessed Output of testcase at -O0


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #6 from kumba at gentoo dot org  2005-12-16 00:51 ---
Created an attachment (id=10510)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10510action=view)
Preprocessed Output of testcase at -O1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437

[Bug middle-end/25437] gcc-4.0.{1,2} produces bad code for -O2 on OpenSSL RC5 Crypto Test

[kumba at gentoo dot org]

--- Comment #7 from kumba at gentoo dot org  2005-12-16 01:55 ---
Got a confirmation the issue exists on Linux/Sparc as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437