[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #18 from Stan Johnson --- $ git clone git://gcc.gnu.org/git/gcc.git $ cd gcc $ git checkout master I'm testing a manual bootstrap of "gcc version 14.0.0 20230524 (experimental) (GCC)" now, accessed via git as shown above. It will still take about 24 more hours for the bootstrap to finish (I'll send an update if it fails), but with gimple-match.cc (and generic-match.cc, which was not affected in my tests) split up, it looks like it will finish ok (it's currently in about the middle of stage 2 and has successfully compiled all the gimple-match-n.cc files). Note that Gentoo's emerge of gcc-13 behaves a little differently than a manual bootstrap. I don't know why, since I think I'm using Gentoo's ./configure options in the manual bootstrap, but in Gentoo's emerge of gcc, they seem to run cc1plus and "as" simultaneously for each compilation, perhaps aggravating the memory issue for gimple-match.cc (or maybe not, since the problem is virtual memory exhausted, not swap space exhausted). Anyway, it looks like the solution was already close. Does anyone know whether the change will be backported to gcc-12 or gcc-13 available from ftp.gnu.org/pub/gnu/gcc? Thanks to all of the GNU developers who continue to make modern tools available for use on old hardware!
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #14 from Stan Johnson --- I can try to capture the offending "cc1plus" and "as" processes just before the compilation of gimple-match.cc fails in stage2; the output will look something like this (for a different cc1plus process number 19431 that is currently running): # cat /proc/19431/maps 8000-82027000 r-xp 08:05 1823425 /var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus 82028000-8202a000 r--p 02028000 08:05 1823425 /var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus 8202a000-82036000 rw-p 0202a000 08:05 1823425 /var/tmp/portage/sys-devel/gcc-13.1.1_p20230520/work/build/prev-gcc/cc1plus 82036000-8207 rwxp 00:00 0 [heap] 8207-82601000 rwxp 00:00 0 [heap] c000-c002 r-xp 08:05 1682956/lib/ld.so.1 c002-c0022000 r--p 0002 08:05 1682956/lib/ld.so.1 c0022000-c0023000 rw-p 00022000 08:05 1682956/lib/ld.so.1 c0023000-c0026000 rw-p 00:00 0 c0028000-c0044000 r-xp 08:05 1515049/usr/lib/libmpc.so.3.3.1 c0044000-c0045000 ---p 0001c000 08:05 1515049/usr/lib/libmpc.so.3.3.1 c0045000-c0046000 r--p 0001b000 08:05 1515049/usr/lib/libmpc.so.3.3.1 c0046000-c0047000 rw-p 0001c000 08:05 1515049/usr/lib/libmpc.so.3.3.1 c0048000-c00b3000 r-xp 08:05 1672972/usr/lib/libmpfr.so.6.2.0 c00b3000-c00b5000 ---p 0006b000 08:05 1672972/usr/lib/libmpfr.so.6.2.0 c00b5000-c00b6000 r--p 0006b000 08:05 1672972/usr/lib/libmpfr.so.6.2.0 c00b6000-c00b7000 rw-p 0006c000 08:05 1672972/usr/lib/libmpfr.so.6.2.0 c00b8000-c0113000 r-xp 08:05 1515186/usr/lib/libgmp.so.10.4.1 c0113000-c0115000 ---p 0005b000 08:05 1515186/usr/lib/libgmp.so.10.4.1 c0115000-c0116000 r--p 0005b000 08:05 1515186/usr/lib/libgmp.so.10.4.1 c0116000-c0117000 rw-p 0005c000 08:05 1515186/usr/lib/libgmp.so.10.4.1 c0118000-c012a000 r-xp 08:05 411479 /lib/libz.so.1.2.13 c012a000-c012b000 ---p 00012000 08:05 411479 /lib/libz.so.1.2.13 c012b000-c012c000 r--p 00011000 08:05 411479 /lib/libz.so.1.2.13 c012c000-c012d000 rw-p 00012000 08:05 411479 /lib/libz.so.1.2.13 c012e000-c0172000 r-xp 08:05 1682625/lib/libm.so.6 c0172000-c0173000 ---p 00044000 08:05 1682625/lib/libm.so.6 c0173000-c0174000 r--p 00043000 08:05 1682625/lib/libm.so.6 c0174000-c0176000 rw-p 00044000 08:05 1682625/lib/libm.so.6 c0176000-c02df000 r-xp 08:05 1682906/lib/libc.so.6 c02df000-c02e ---p 00169000 08:05 1682906/lib/libc.so.6 c02e-c02e2000 r--p 0016a000 08:05 1682906/lib/libc.so.6 c02e2000-c02e6000 rw-p 0016c000 08:05 1682906/lib/libc.so.6 c02e6000-c0ad2000 rw-p 00:00 0 c0ad5000-c25dd000 rw-p 00:00 0 ef91f000-ef948000 rw-p 00:00 0 [stack] > Git checkout master Thanks, I'll try compiling that version manually and also capture the relevant /proc output.
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #10 from Stan Johnson --- > The question is how much virtual memory is exposed to a user > process, that is - how large is the address space? I'm not sure, but I see this: $ prlimit RESOURCE DESCRIPTION SOFT HARD UNITS AS address space limitunlimited unlimited bytes CORE max core file size 0 unlimited bytes CPUCPU time unlimited unlimited seconds DATA max data size unlimited unlimited bytes FSIZE max file size unlimited unlimited bytes LOCKS max number of file locks held unlimited unlimited locks MEMLOCKmax locked-in-memory address space 8388608 8388608 bytes MSGQUEUE max bytes in POSIX mqueues819200819200 bytes NICE max nice prio allowed to raise 0 0 NOFILE max number of open files1024 4096 files NPROC max number of processes26236 26236 processes RSSmax resident set size unlimited unlimited bytes RTPRIO max real-time priority 0 0 RTTIME timeout for real-time tasksunlimited unlimited microsecs SIGPENDING max number of pending signals 26236 26236 signals STACK max stack size 8388608 unlimited bytes As long as those are also the limits for portage, it should be ok. > Note mainline would be gcc 14.0, you can probably download a recent > snapshot. ok, I've downloaded the latest gcc snapshot using git. I'll try a manual bootstrap of that. Do you recommend that I use QEMU m68k (virt) running Debian SID or Gentoo, or doesn't it matter?
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #8 from Stan Johnson --- > How much virtual memory does the m68k host have? Swap space in the m68k virt VM is configurable; I'm using 1 GiB in two 512 MiB partitions. I noticed that compilation goes further with two 512 MiB partitions that with one 1 GiB partition, even though the second 512 MiB swap partition isn't used (see above). And I know I tested 2 GiB swap at one point, and that also failed. The virt VM is configured with 3399672K memory. While observing the failure, it appears to happen when the assembler "as" becomes more active (so probably when cc1plus is about done). Assembler memory increases quickly, and swap space is not really exhausted, despite the error message. > Can you try current mainline to see if that's enough to pass native > bootstrap in qemu? Native (manual) bootstrap of gcc-13.1 in QEMU (virt and q800) failed in Gentoo, but the failure was slightly different (it failed in stage 3 instead of stage 2). And I used Gentoo's configure options, as documented above. I could try no configure options, followed by "make bootstrap"; would that be helpful? If yes, should I use Gentoo or Debian SID?
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #6 from Stan Johnson --- Thanks, let me know if you need me to check anything here. The problem has existed since at least gcc-12. Initially I thought the QEMU q800 VM had run out of memory, but switching to a virt VM with ~3 GB memory and 1 GiB swap also failed. Further checking showed that the virt VM was not actually out of memory (unless I wasn't able to monitor memory changes quickly enough looking at /proc/swaps and /proc/meminfo every minute).
[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 --- Comment #4 from Stan Johnson --- Adding more swap space doesn't help. The latest Gentoo update attempted to merge gcc-13.1.1_p20230520, and it failed while compiling gimple-match.cc in stage2. The error message is "virtual memory exhausted: Cannot allocate memory". Here are some memory details just before the failure: ./work/build/./prev-gcc/cc1plus VSZ=920260 RSS=632200 /usr/m68k-unknown-linux-gnu/bin/as VSZ=265260 RSS=258608 There is still swap space available: # cat /proc/swaps Filename Type Size Used Priority /dev/sda7 partition 524284225008-2 /dev/sda8 partition 5242840 -3
[Bug bootstrap/109927] New: Bootstrap fails for m68k in stage2 compilation of gimple-match.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Bug ID: 109927 Summary: Bootstrap fails for m68k in stage2 compilation of gimple-match.cc Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: userm57 at yahoo dot com Target Milestone: --- Hello, Bootstrap of gcc 13.1.0 fails during compilation of gimple-match.cc. The error message is "virtual memory exhausted: Cannot allocate memory", possibly from the assembler. However, virtual memory is not really exhausted. A slightly different version of (possibly) the same error occurs during stage3 compilation of gimple-match.cc (see below). Setup: 1) Install QEMU. I'm using QEMU version 7.2.1 on an HP Z2 workstation (32 GiB, eight i7 CPUs) running Debian SID. 2) Install Gentoo to a disk image or a separate disk (using whatever your usual procedure is for installing Gentoo). I used the latest Gentoo stage3 for m68k for the first procedure below, and a fully installed Gentoo for the second procedure. For swap space, I tried many options, ending up with two 512 MiB swap partitions. Regardless of how much swap space is used, compilation of gimple-match.cc will fail with the same error. To generate the error in stage2 gcc bootstrap, the following steps can be used: 1) Create a QEMU virtual machine (VM) configured as q800 (e.g. "-M q800 -m 1004M") or as virt (e.g. "-M virt -m 3399672K"). Using q800, you can use the latest default Debian kernel for m68k; otherwise, you'll need a virt kernel. They will have the same error. 2) It's not necessary to configure the network, users, etc. in the Gentoo QEMU VM (instead use the chroot environment). After installation of the Gentoo stage3 as per the Gentoo installation instructions, you can run "emerge-webrsync" then "emerge gcc" from the chroot. Compilation will fail in gcc stage2. To generate the error in a manual gcc compilation, the following steps can be used: 1) If you have a completed installation of Gentoo or Debian, you can download the latest gcc. I used Gentoo's configure options (but not their patches): "../gcc-13.1.0/configure --host=m68k-unknown-linux-gnu --build=m68k-unknown-linux-gnu --prefix=/usr --bindir=/usr/m68k-unknown-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/m68k-unknown-linux-gnu/13/include --datadir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13 --mandir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13/man --infodir=/usr/share/gcc-data/m68k-unknown-linux-gnu/13/info --with-gxx-include-dir=/usr/lib/gcc/m68k-unknown-linux-gnu/13/include/g++-v13 --with-python-dir=/share/gcc-data/m68k-unknown-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --disable-libunwind-exceptions --with-gcc-major-version-only --disable-esp --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp" followed by "make bootstrap". 2) The compilation should eventually fail in stage3 gcc bootstrap while compiling gimple-match.cc. I'll be happy to provide any additional details or clarifications that you may require. Thank you for your help. -Stan Johnson
