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

2018-01-18 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #12 from Eric Botcazou  ---
I can reproduce with a cross-compiler on x86-64/Linux.

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

2018-01-17 Thread 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

2018-01-17 Thread 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

2018-01-17 Thread 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

2018-01-17 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443

--- Comment #8 from Eric Botcazou  ---
> 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.

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

2018-01-17 Thread 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

2018-01-17 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  ---
Please retry with the current 7 branch, it contains additional fixes.

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

2018-01-15 Thread 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

2018-01-15 Thread 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

2017-07-17 Thread 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

2017-07-17 Thread 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] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory

2017-07-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443

Richard Biener  changed:

   What|Removed |Added

 Target||mips
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-17
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
What file is it compiling?