https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #3 from Joshua Kinard <kumba at gentoo dot org> --- 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 runaway....something....going 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.
