public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c/54179] New: please split insn-emit.c ! @ 2012-08-05 11:05 jason.vas.dias at gmail dot com 2012-08-05 11:11 ` [Bug c/54179] " jason.vas.dias at gmail dot com ` (40 more replies) 0 siblings, 41 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 11:05 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Bug #: 54179 Summary: please split insn-emit.c ! Classification: Unclassified Product: gcc Version: lto Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned@gcc.gnu.org ReportedBy: jason.vas.dias@gmail.com I've been attempting to build a "C" only bootstrap 4.7.1 compiler on x86_64 Linux. Building the Stage1 and Stage2 compilers takes @ 8 hours on my 2.2Ghz machine - which I have to continually cycle down to 800Mhz for 2 seconds every 8 seconds with a script under Linux 3.4.4, otherwise I get overheating emergency reboots - nice! But with -lto enabled, the build of Stage 3 compiler gets to trying to build insn-emit.c , but has not yet completed given a previous two-day run - during which I have to be careful not to do any extra activity which might tip the machine past the 105 degree emergency reboot trip-point - so basically I have to lock up my laptop in a freezer for 3-days plus in order to build gcc : $ ps -lp $(pgrep cc1) F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 R 0 3863 3862 99 80 0 - 64611 - pts/5 20:43:01 cc1 $ tr '\0' ' ' < /proc/3863/cmdline /mnt/sda3/gcc/./prev-gcc/cc1 -quiet -I . -I . -I /usr/build2/gcc/gcc-4.7.1/gcc -I /usr/build2/gcc/gcc-4.7.1/gcc/. -I /usr/build2/gcc/gcc-4.7.1/gcc/../include -I /usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include -I /usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber -I /usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I ../libdecnumber -iprefix /mnt/sda3/gcc/prev-gcc/../lib64/gcc/x86_64-pc-linux-gnu/4.7.1/ -isystem /mnt/sda3/gcc/./prev-gcc/include -isystem /mnt/sda3/gcc/./prev-gcc/include-fixed -D IN_GCC -D HAVE_CONFIG_H -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include insn-emit.c -quiet -dumpbase insn-emit.c -mtune=k8 -march=x86-64 -auxbase-strip insn-emit.o -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -o /tmp/ccgsb5Pk.s $ ls -l /mnt/sda3/gcc/gcc/insn-emit.c -rw-r--r-- 1 root devel 1793209 Jul 22 22:13 /mnt/sda3/gcc/gcc/insn-emit.c $ ls -l /tmp/ccgsb5Pk.s -rw------- 1 root root 1101824 Aug 5 11:00 /tmp/ccgsb5Pk.s $ cat /proc/3863/map $ cat /proc/3863/maps | wc -l 5310 Wow, that's alot of maps ! 00400000-05c20000 r-xp 00000000 08:03 132489 /mnt/sda3/gcc/prev-gcc/cc1 05e1f000-05e2b000 rw-p 0581f000 08:03 132489 /mnt/sda3/gcc/prev-gcc/cc1 7fd59f821000-7fd59f836000 r-xp 00000000 08:03 135449 /mnt/sda3/gcc/prev-gcc/libgcc_s.so.1 7fd59f836000-7fd59fa35000 ---p 00015000 08:03 135449 /mnt/sda3/gcc/prev-gcc/libgcc_s.so.1 7fd59fa35000-7fd59fa36000 rw-p 00014000 08:03 135449 /mnt/sda3/gcc/prev-gcc/libgcc_s.so.1 7fd59fa36000-7fd59fb2e000 r-xp 00000000 08:06 772762 /lib64/libm-2.16.so 7fd59fb2e000-7fd59fd2d000 ---p 000f8000 08:06 772762 /lib64/libm-2.16.so 7fd59fd2d000-7fd59fd2e000 r--p 000f7000 08:06 772762 /lib64/libm-2.16.so 7fd59fd2e000-7fd59fd2f000 rw-p 000f8000 08:06 772762 /lib64/libm-2.16.so 7fd59fd2f000-7fd59fe13000 r-xp 00000000 08:06 184127 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15 7fd59fe13000-7fd5a0013000 ---p 000e4000 08:06 184127 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15 7fd5a0013000-7fd5a001b000 r--p 000e4000 08:06 184127 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15 7fd5a001b000-7fd5a001d000 rw-p 000ec000 08:06 184127 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.0/libstdc++.so.6.0.15 7fd5a0032000-7fd5a0063000 r-xp 00000000 08:06 147372 /usr/lib64/libpolylib64.so.8.1.0 7fd5a0063000-7fd5a0263000 ---p 00031000 08:06 147372 /usr/lib64/libpolylib64.so.8.1.0 7fd5a0263000-7fd5a0264000 rw-p 00031000 08:06 147372 /usr/lib64/libpolylib64.so.8.1.0 7fd5a0268000-7fd5a0405000 r-xp 00000000 08:06 868371 /lib64/libc-2.16.so 7fd5a0405000-7fd5a0604000 ---p 0019d000 08:06 868371 /lib64/libc-2.16.so 7fd5a0604000-7fd5a0608000 r--p 0019c000 08:06 868371 /lib64/libc-2.16.so 7fd5a0608000-7fd5a060a000 rw-p 001a0000 08:06 868371 /lib64/libc-2.16.so 7fd5a060e000-7fd5a0626000 r-xp 00000000 08:06 150900 /usr/lib64/libz.so.1.2.5 7fd5a0626000-7fd5a0825000 ---p 00018000 08:06 150900 /usr/lib64/libz.so.1.2.5 7fd5a0825000-7fd5a0826000 rw-p 00017000 08:06 150900 /usr/lib64/libz.so.1.2.5 7fd5a0826000-7fd5a0828000 r-xp 00000000 08:06 772761 /lib64/libdl-2.16.so 7fd5a0828000-7fd5a0a28000 ---p 00002000 08:06 772761 /lib64/libdl-2.16.so 7fd5a0a28000-7fd5a0a29000 r--p 00002000 08:06 772761 /lib64/libdl-2.16.so 7fd5a0a29000-7fd5a0a2a000 rw-p 00003000 08:06 772761 /lib64/libdl-2.16.so 7fd5a0a2a000-7fd5a0a8c000 r-xp 00000000 08:06 155396 /usr/lib64/libgmp.so.10.0.4 7fd5a0a8c000-7fd5a0c8c000 ---p 00062000 08:06 155396 /usr/lib64/libgmp.so.10.0.4 7fd5a0c8c000-7fd5a0c95000 rw-p 00062000 08:06 155396 /usr/lib64/libgmp.so.10.0.4 7fd5a0c95000-7fd5a0ceb000 r-xp 00000000 08:06 154706 /usr/lib64/libmpfr.so.4.1.0 7fd5a0ceb000-7fd5a0eea000 ---p 00056000 08:06 154706 /usr/lib64/libmpfr.so.4.1.0 7fd5a0eea000-7fd5a0eec000 rw-p 00055000 08:06 154706 /usr/lib64/libmpfr.so.4.1.0 7fd5a0eec000-7fd5a0efe000 r-xp 00000000 08:06 151501 /usr/lib64/libmpc.so.2.0.0 7fd5a0efe000-7fd5a10fe000 ---p 00012000 08:06 151501 /usr/lib64/libmpc.so.2.0.0 7fd5a10fe000-7fd5a10ff000 rw-p 00012000 08:06 151501 /usr/lib64/libmpc.so.2.0.0 7fd5a10ff000-7fd5a1102000 r-xp 00000000 08:06 155397 /usr/lib64/libgmpxx.so.4.2.4 7fd5a1102000-7fd5a1302000 ---p 00003000 08:06 155397 /usr/lib64/libgmpxx.so.4.2.4 7fd5a1302000-7fd5a1303000 rw-p 00003000 08:06 155397 /usr/lib64/libgmpxx.so.4.2.4 7fd5a1304000-7fd5a1308000 r-xp 00000000 08:06 152307 /usr/lib64/libpwl.so.5.0.0 7fd5a1308000-7fd5a1507000 ---p 00004000 08:06 152307 /usr/lib64/libpwl.so.5.0.0 7fd5a1507000-7fd5a1508000 rw-p 00003000 08:06 152307 /usr/lib64/libpwl.so.5.0.0 7fd5a1508000-7fd5a15ee000 r-xp 00000000 08:06 152313 /usr/lib64/libppl.so.9.0.0 7fd5a15ee000-7fd5a17ee000 ---p 000e6000 08:06 152313 /usr/lib64/libppl.so.9.0.0 7fd5a17ee000-7fd5a17f1000 rw-p 000e6000 08:06 152313 /usr/lib64/libppl.so.9.0.0 7fd5a17f1000-7fd5a1cdf000 r-xp 00000000 08:06 180199 /usr/lib64/libppl_c.so.4.0.0 7fd5a1cdf000-7fd5a1ede000 ---p 004ee000 08:06 180199 /usr/lib64/libppl_c.so.4.0.0 7fd5a1ede000-7fd5a1ee3000 rw-p 004ed000 08:06 180199 /usr/lib64/libppl_c.so.4.0.0 7fd5a1ee4000-7fd5a1f03000 r-xp 00000000 08:06 147395 /usr/lib64/libcloog.so.0.0.0 7fd5a1f03000-7fd5a2102000 ---p 0001f000 08:06 147395 /usr/lib64/libcloog.so.0.0.0 7fd5a2102000-7fd5a2103000 rw-p 0001e000 08:06 147395 /usr/lib64/libcloog.so.0.0.0 7fd5a2105000-7fd5a2126000 r-xp 00000000 08:06 998045 /lib64/ld-2.16.so 7fd5a2326000-7fd5a2327000 r--p 00021000 08:06 998045 /lib64/ld-2.16.so 7fd5a2327000-7fd5a2328000 rw-p 00022000 08:06 998045 /lib64/ld-2.16.so ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com @ 2012-08-05 11:11 ` jason.vas.dias at gmail dot com 2012-08-05 11:22 ` wbrana at gmail dot com ` (39 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 11:11 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #1 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 11:11:28 UTC --- Why must we compile 1.8MB of insn-emit.c ? Can't it be split up ? Why is gcc-4.7.1 SO much slower ? ie. evidently the Stage1 and Stage2 compilers were able to build insn-emit.c in acceptable time. Why is the Stage3 compiler unable to do it in over 2 days ?? Why over 5000 memory maps ? When I strace the process, all it seems to be doing is managing this vast amount of memory : $ strace -tfp 3863 Process 3863 attached - interrupt to quit 11:10:24 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0 11:10:24 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd3f95b8000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd4d9c15000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd4d9c11000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd3f95b7000, 4096, MADV_DONTNEED) = 0 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com 2012-08-05 11:11 ` [Bug c/54179] " jason.vas.dias at gmail dot com @ 2012-08-05 11:22 ` wbrana at gmail dot com 2012-08-05 11:36 ` jason.vas.dias at gmail dot com ` (38 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: wbrana at gmail dot com @ 2012-08-05 11:22 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 wbrana <wbrana at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wbrana at gmail dot com --- Comment #2 from wbrana <wbrana at gmail dot com> 2012-08-05 11:22:24 UTC --- Your PC is broken. C only build with 3 stages takes about 18 minutes with -j2 on my PC. Compilation of small count of big files is faster than big count of small files. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com 2012-08-05 11:11 ` [Bug c/54179] " jason.vas.dias at gmail dot com 2012-08-05 11:22 ` wbrana at gmail dot com @ 2012-08-05 11:36 ` jason.vas.dias at gmail dot com 2012-08-05 11:43 ` jason.vas.dias at gmail dot com ` (37 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 11:36 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #3 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 11:36:05 UTC --- RE: > Your PC is broken. Comments such as these don't help much. No, only Linux 3.4+ temperature management is. I'm working with the Linux developers to resolve this . Meanwhile, I'm stuck with gcc-4.6.0, which I'd like to do something about. > C only build with 3 stages takes about 18 minutes with -j2 > on my PC. And what type of super-computer is that ? > Compilation of small count of big files is faster than big count of small > files. Not in my experience. Why force such huge memory resource demands ? I guess as usual no help is to be expected from gcc-bugs - I'll have to modify genemit.c myself. One final try before I go modifying genemit.c : Can anyone suggest what state cc1 is in when it shows this 20 minute strace: $ strace -tfp 3863 Process 3863 attached - interrupt to quit 11:10:24 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0 11:10:24 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd3f95b8000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd4d9c15000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd4d9c11000, 4096, MADV_DONTNEED) = 0 11:10:33 madvise(0x7fd3f95b7000, 4096, MADV_DONTNEED) = 0 11:11:09 madvise(0x7fd59ef79000, 16384, MADV_DONTNEED) = 0 11:11:09 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:11:20 madvise(0x7fd3f95b1000, 4096, MADV_DONTNEED) = 0 11:11:20 madvise(0x7fd4d9c17000, 4096, MADV_DONTNEED) = 0 11:11:56 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:11:56 madvise(0x7fd3f95b1000, 4096, MADV_DONTNEED) = 0 11:12:04 write(3, "ax, %rsi\n\tjmp\t.L1804\n\t.cfi_endpr"..., 4096) = 4096 11:12:04 madvise(0x7fd3f95a6000, 4096, MADV_DONTNEED) = 0 11:12:04 madvise(0x7fd59ef75000, 16384, MADV_DONTNEED) = 0 11:12:04 madvise(0x7fd4d9c1b000, 4096, MADV_DONTNEED) = 0 11:12:04 madvise(0x7fd4d9c16000, 4096, MADV_DONTNEED) = 0 11:12:46 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:12:46 madvise(0x7fd3f95a6000, 4096, MADV_DONTNEED) = 0 11:12:55 madvise(0x7fd3f95ec000, 4096, MADV_DONTNEED) = 0 11:12:55 madvise(0x7fd3f95ab000, 4096, MADV_DONTNEED) = 0 11:12:55 madvise(0x7fd4971f4000, 4096, MADV_DONTNEED) = 0 11:12:55 madvise(0x7fd4d9c21000, 4096, MADV_DONTNEED) = 0 11:12:55 madvise(0x7fd4d9c0e000, 4096, MADV_DONTNEED) = 0 11:13:31 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:13:31 madvise(0x7fd3f95ec000, 4096, MADV_DONTNEED) = 0 11:13:44 madvise(0x7fd3f95a8000, 4096, MADV_DONTNEED) = 0 11:13:44 madvise(0x7fd4d9c24000, 4096, MADV_DONTNEED) = 0 11:13:44 madvise(0x7fd4d9c20000, 4096, MADV_DONTNEED) = 0 11:13:44 madvise(0x7fd3f95a4000, 4096, MADV_DONTNEED) = 0 11:14:14 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:14:14 madvise(0x7fd3f95a8000, 4096, MADV_DONTNEED) = 0 11:14:22 madvise(0x7fd3f95a1000, 4096, MADV_DONTNEED) = 0 11:14:22 madvise(0x7fd4d9fda000, 4096, MADV_DONTNEED) = 0 11:14:22 madvise(0x7fd4d9c27000, 4096, MADV_DONTNEED) = 0 11:14:53 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:14:53 madvise(0x7fd3f95a1000, 4096, MADV_DONTNEED) = 0 11:14:59 madvise(0x7fd3f959d000, 4096, MADV_DONTNEED) = 0 11:14:59 madvise(0x7fd4d9c2a000, 4096, MADV_DONTNEED) = 0 11:14:59 madvise(0x7fd4d9c25000, 4096, MADV_DONTNEED) = 0 11:15:29 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:15:29 madvise(0x7fd3f959d000, 4096, MADV_DONTNEED) = 0 11:15:36 madvise(0x7fd3f9599000, 4096, MADV_DONTNEED) = 0 11:15:36 madvise(0x7fd4d9c2c000, 4096, MADV_DONTNEED) = 0 11:16:10 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:16:10 madvise(0x7fd3f9599000, 4096, MADV_DONTNEED) = 0 11:16:16 write(3, "1699:\n\t.cfi_startproc\n\tmovq\t%rbx"..., 4096) = 4096 11:16:17 madvise(0x7fd3f9596000, 4096, MADV_DONTNEED) = 0 11:16:17 madvise(0x7fd4d9c2d000, 4096, MADV_DONTNEED) = 0 11:16:17 madvise(0x7fd4d9c2b000, 4096, MADV_DONTNEED) = 0 11:16:17 madvise(0x7fd3f9594000, 4096, MADV_DONTNEED) = 0 11:16:50 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:16:50 madvise(0x7fd3f9596000, 4096, MADV_DONTNEED) = 0 11:16:57 madvise(0x7fd3f95e1000, 4096, MADV_DONTNEED) = 0 11:16:57 madvise(0x7fd3f958e000, 4096, MADV_DONTNEED) = 0 11:16:57 madvise(0x7fd4d9c30000, 4096, MADV_DONTNEED) = 0 11:17:18 madvise(0x7fd4d9f72000, 4096, MADV_DONTNEED) = 0 11:17:28 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:17:28 madvise(0x7fd4d9f72000, 4096, MADV_DONTNEED) = 0 11:17:31 madvise(0x7fd4d9f72000, 4096, MADV_DONTNEED) = 0 11:17:31 madvise(0x7fd4d9f72000, 4096, MADV_DONTNEED) = 0 11:17:34 madvise(0x7fd4d9f72000, 4096, MADV_DONTNEED) = 0 11:17:34 madvise(0x7fd4d9c32000, 4096, MADV_DONTNEED) = 0 11:17:34 madvise(0x7fd4d9c2f000, 4096, MADV_DONTNEED) = 0 11:17:34 madvise(0x7fd4d9c1a000, 4096, MADV_DONTNEED) = 0 11:18:05 madvise(0x7fd59ef75000, 16384, MADV_DONTNEED) = 0 11:18:05 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:18:12 madvise(0x7fd3f958a000, 4096, MADV_DONTNEED) = 0 11:18:12 madvise(0x7fd59ef71000, 16384, MADV_DONTNEED) = 0 11:18:12 madvise(0x7fd4d9c37000, 4096, MADV_DONTNEED) = 0 11:18:12 madvise(0x7fd4d9c34000, 4096, MADV_DONTNEED) = 0 11:18:42 madvise(0x7fd59ef71000, 16384, MADV_DONTNEED) = 0 11:18:42 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:18:47 write(3, "redf4:\n.LFB1705:\n\t.cfi_startproc"..., 4096) = 4096 11:18:48 madvise(0x7fd4d9fc8000, 4096, MADV_DONTNEED) = 0 11:18:48 madvise(0x7fd59ef6d000, 16384, MADV_DONTNEED) = 0 11:18:48 madvise(0x7fd4d9c41000, 4096, MADV_DONTNEED) = 0 11:18:48 madvise(0x7fd4d9c3f000, 4096, MADV_DONTNEED) = 0 11:19:16 madvise(0x7fd59ef6d000, 16384, MADV_DONTNEED) = 0 11:19:16 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:19:23 madvise(0x7fd3f9587000, 4096, MADV_DONTNEED) = 0 11:19:23 madvise(0x7fd3f9585000, 4096, MADV_DONTNEED) = 0 11:19:23 madvise(0x7fd59ef69000, 16384, MADV_DONTNEED) = 0 11:19:23 madvise(0x7fd4d9c46000, 4096, MADV_DONTNEED) = 0 11:19:23 madvise(0x7fd4d9c44000, 4096, MADV_DONTNEED) = 0 11:19:51 madvise(0x7fd59ef69000, 16384, MADV_DONTNEED) = 0 11:19:51 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:19:56 madvise(0x7fd59ef65000, 16384, MADV_DONTNEED) = 0 11:19:56 madvise(0x7fd4d9c4d000, 4096, MADV_DONTNEED) = 0 11:19:56 madvise(0x7fd4d9c4b000, 4096, MADV_DONTNEED) = 0 11:19:56 madvise(0x7fd3f9581000, 4096, MADV_DONTNEED) = 0 11:20:25 madvise(0x7fd59ef65000, 16384, MADV_DONTNEED) = 0 11:20:25 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:20:30 write(3, "%rax, %rsi\n\txorl\t%eax, %eax\n\tcal"..., 4096) = 4096 11:20:31 madvise(0x7fd3f957e000, 4096, MADV_DONTNEED) = 0 11:20:31 madvise(0x7fd59ef61000, 16384, MADV_DONTNEED) = 0 11:20:31 madvise(0x7fd4d9c53000, 4096, MADV_DONTNEED) = 0 11:20:31 madvise(0x7fd4d9c51000, 4096, MADV_DONTNEED) = 0 11:21:01 madvise(0x7fd59ef61000, 16384, MADV_DONTNEED) = 0 11:21:01 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:21:07 madvise(0x7fd59ef5d000, 16384, MADV_DONTNEED) = 0 11:21:07 madvise(0x7fd4d9c5b000, 4096, MADV_DONTNEED) = 0 11:21:07 madvise(0x7fd4d9c5a000, 4096, MADV_DONTNEED) = 0 11:21:34 madvise(0x7fd59ef5d000, 16384, MADV_DONTNEED) = 0 11:21:34 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:21:39 write(3, "2\n\tcall\trtx_alloc_stat\n\tmovl\t$23"..., 4096) = 4096 11:21:41 madvise(0x7fd3f9575000, 4096, MADV_DONTNEED) = 0 11:21:41 madvise(0x7fd4961f3000, 4096, MADV_DONTNEED) = 0 11:21:41 madvise(0x7fd59ef59000, 16384, MADV_DONTNEED) = 0 11:21:41 madvise(0x7fd4d9c60000, 4096, MADV_DONTNEED) = 0 11:21:41 madvise(0x7fd4d9c5f000, 4096, MADV_DONTNEED) = 0 11:22:04 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:22:04 madvise(0x7fd3f9575000, 4096, MADV_DONTNEED) = 0 11:22:07 madvise(0x7fd4967f2000, 4096, MADV_DONTNEED) = 0 11:22:07 madvise(0x7fd3f957b000, 4096, MADV_DONTNEED) = 0 11:22:24 madvise(0x7fd3f95ed000, 4096, MADV_DONTNEED) = 0 11:22:33 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:22:33 madvise(0x7fd3f95ed000, 4096, MADV_DONTNEED) = 0 11:22:38 madvise(0x7fd59ef59000, 16384, MADV_DONTNEED) = 0 11:22:38 madvise(0x7fd4d9c67000, 4096, MADV_DONTNEED) = 0 11:22:38 madvise(0x7fd4d9c64000, 4096, MADV_DONTNEED) = 0 11:23:01 madvise(0x7fd59ef59000, 16384, MADV_DONTNEED) = 0 11:23:01 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:23:07 madvise(0x7fd4d9c4f000, 4096, MADV_DONTNEED) = 0 11:23:07 madvise(0x7fd3f9570000, 4096, MADV_DONTNEED) = 0 11:23:07 madvise(0x7fd3f9584000, 4096, MADV_DONTNEED) = 0 11:23:07 madvise(0x7fd59ef55000, 16384, MADV_DONTNEED) = 0 11:23:07 madvise(0x7fd4d9c6c000, 4096, MADV_DONTNEED) = 0 11:23:29 madvise(0x7fd59ef55000, 16384, MADV_DONTNEED) = 0 11:23:29 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:23:33 write(3, "equence\n\tmovq\t8(%rsp), %rbp\n\tmov"..., 4096) = 4096 11:23:33 madvise(0x7fd3f9574000, 4096, MADV_DONTNEED) = 0 11:23:33 madvise(0x7fd59ef51000, 16384, MADV_DONTNEED) = 0 11:23:33 madvise(0x7fd4d9c70000, 4096, MADV_DONTNEED) = 0 11:23:33 madvise(0x7fd4d9c6a000, 4096, MADV_DONTNEED) = 0 11:23:33 madvise(0x7fd3f956c000, 4096, MADV_DONTNEED) = 0 11:23:58 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:23:58 madvise(0x7fd3f9574000, 4096, MADV_DONTNEED) = 0 11:24:07 madvise(0x7fd4953f2000, 4096, MADV_DONTNEED) = 0 11:24:07 madvise(0x7fd4d9c6f000, 4096, MADV_DONTNEED) = 0 11:24:36 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:24:36 madvise(0x7fd4953f2000, 4096, MADV_DONTNEED) = 0 11:24:44 madvise(0x7fd4d9c31000, 4096, MADV_DONTNEED) = 0 11:25:02 madvise(0x7fd3f9566000, 4096, MADV_DONTNEED) = 0 11:25:12 madvise(0x7fd59ef51000, 16384, MADV_DONTNEED) = 0 11:25:12 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:25:19 madvise(0x7fd4d9c77000, 4096, MADV_DONTNEED) = 0 11:25:19 madvise(0x7fd4d9c75000, 4096, MADV_DONTNEED) = 0 11:25:19 madvise(0x7fd3f9561000, 4096, MADV_DONTNEED) = 0 11:25:51 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:25:51 madvise(0x7fd4d9c77000, 4096, MADV_DONTNEED) = 0 11:25:58 madvise(0x7fd4d9c7b000, 4096, MADV_DONTNEED) = 0 11:26:27 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:26:27 madvise(0x7fd4d9c7b000, 4096, MADV_DONTNEED) = 0 11:26:34 madvise(0x7fd494df3000, 4096, MADV_DONTNEED) = 0 11:26:34 madvise(0x7fd496ff2000, 4096, MADV_DONTNEED) = 0 11:26:34 madvise(0x7fd4d9c79000, 4096, MADV_DONTNEED) = 0 11:27:03 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:27:03 madvise(0x7fd494df3000, 4096, MADV_DONTNEED) = 0 11:27:09 write(3, "all\trtx_alloc_stat\n\tmovl\t$16, %e"..., 4096) = 4096 11:27:44 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:27:44 madvise(0x7fd494df3000, 4096, MADV_DONTNEED) = 0 11:27:52 madvise(0x7fd3f955a000, 4096, MADV_DONTNEED) = 0 11:27:52 madvise(0x7fd4d9c7c000, 4096, MADV_DONTNEED) = 0 11:27:52 madvise(0x7fd3f9559000, 4096, MADV_DONTNEED) = 0 11:28:25 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:28:25 madvise(0x7fd3f955a000, 4096, MADV_DONTNEED) = 0 11:29:07 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:29:07 madvise(0x7fd3f955a000, 4096, MADV_DONTNEED) = 0 11:29:14 madvise(0x7fd4d9c7e000, 4096, MADV_DONTNEED) = 0 11:29:14 madvise(0x7fd4d9c76000, 4096, MADV_DONTNEED) = 0 11:29:42 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:29:42 madvise(0x7fd4d9c7e000, 4096, MADV_DONTNEED) = 0 11:29:48 madvise(0x7fd4d9c84000, 4096, MADV_DONTNEED) = 0 11:30:19 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:30:19 madvise(0x7fd4d9c84000, 4096, MADV_DONTNEED) = 0 11:30:25 madvise(0x7fd4943f2000, 4096, MADV_DONTNEED) = 0 11:30:25 madvise(0x7fd4d9c85000, 4096, MADV_DONTNEED) = 0 11:30:25 madvise(0x7fd4d9c82000, 4096, MADV_DONTNEED) = 0 11:30:25 madvise(0x7fd3f9551000, 4096, MADV_DONTNEED) = 0 11:30:55 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:30:55 madvise(0x7fd4943f2000, 4096, MADV_DONTNEED) = 0 11:31:00 write(3, "5\n\t.globl\tgen_movhi\n\t.type\tgen_m"..., 4096) = 4096 11:31:01 madvise(0x7fd59ef51000, 16384, MADV_DONTNEED) = 0 11:31:01 madvise(0x7fd4d9c88000, 4096, MADV_DONTNEED) = 0 11:31:35 madvise(0x7fd59ef51000, 16384, MADV_DONTNEED) = 0 11:31:35 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:31:40 madvise(0x7fd4d9c8c000, 4096, MADV_DONTNEED) = 0 11:31:40 madvise(0x7fd4d9c87000, 4096, MADV_DONTNEED) = 0 11:32:04 madvise(0x7fd3f954d000, 4096, MADV_DONTNEED) = 0 11:32:14 madvise(0x7fd59ef51000, 16384, MADV_DONTNEED) = 0 11:32:14 madvise(0x7fd59f1b7000, 8192, MADV_DONTNEED) = 0 11:32:17 madvise(0x7fd3f954d000, 4096, MADV_DONTNEED) = 0 11:32:22 madvise(0x7fd3f957f000, 4096, MADV_DONTNEED) = 0 11:32:22 madvise(0x7fd3f9538000, 4096, MADV_DONTNEED) = 0 11:32:22 madvise(0x7fd3f9556000, 4096, MADV_DONTNEED) = 0 11:32:22 madvise(0x7fd4d9c8e000, 4096, MADV_DONTNEED) = 0 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (2 preceding siblings ...) 2012-08-05 11:36 ` jason.vas.dias at gmail dot com @ 2012-08-05 11:43 ` jason.vas.dias at gmail dot com 2012-08-05 12:01 ` wbrana at gmail dot com ` (36 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 11:43 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #4 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 11:43:03 UTC --- in case the configuration is relevant: <quote file="config.log"> It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=c --disable-build-with-cxx --disable- build-poststage1-with-cxx --enable-stage1-checking=all --enable-stage1-languages=c --enable-targets=all --enable-multilib --enable-threads=posix --enable-tls --enable -lto --enable-shared --enable-checking=release --with-build-time-tools=/usr/bin --with-ld=/usr/bin/ld --with-gnu-ld --with-as=/usr/bin/as --with-gnu-as --enable-versi on-specific-runtime-libs --with-system-zlib --without-included-gettext --enable-bootstrap --enable-serial-configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux -gnu ## --------- ## ## Platform. ## ## --------- ## hostname = jvdspc uname -m = x86_64 uname -r = 3.4.4-jvd+ uname -s = Linux uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: . PATH: /bin PATH: /usr/bin PATH: /sbin PATH: /usr/sbin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2237: checking build system type configure:2251: result: x86_64-pc-linux-gnu </quote> And I ran : $ make -j2 bootstrap 2>&1 | tee make.bootstrap.log ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (3 preceding siblings ...) 2012-08-05 11:43 ` jason.vas.dias at gmail dot com @ 2012-08-05 12:01 ` wbrana at gmail dot com 2012-08-05 12:04 ` steven at gcc dot gnu.org ` (35 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: wbrana at gmail dot com @ 2012-08-05 12:01 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #5 from wbrana <wbrana at gmail dot com> 2012-08-05 12:00:50 UTC --- (In reply to comment #3) > And what type of super-computer is that ? outdated, almost 5 years old: Core 2 Quad 3.2 GHz, 4 GB RAM ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (4 preceding siblings ...) 2012-08-05 12:01 ` wbrana at gmail dot com @ 2012-08-05 12:04 ` steven at gcc dot gnu.org 2012-08-05 12:21 ` jason.vas.dias at gmail dot com ` (34 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 12:04 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Steven Bosscher <steven at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |steven at gcc dot gnu.org --- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 12:03:46 UTC --- (In reply to comment #3) > RE: > > Your PC is broken. > Comments such as these don't help much. Indeed. However, your bug report wasn't very useful either before you shared your configuration. There are some hints for what's needed for GCC developers to understand and investigate a bug in the web pages: http://gcc.gnu.org/bugs/ > > C only build with 3 stages takes about 18 minutes with -j2 > > on my PC. > > And what type of super-computer is that ? For me it's a HP Pavilion dv9000 and it takes just over 20 minutes. > > Compilation of small count of big files is faster than big count of small > > files. > > Not in my experience. Why force such huge memory resource demands ? I think it's due to --enable-stage1-checking=all. This enables a bunch of really expensive checks. > I guess as usual no help is to be expected from gcc-bugs - I'll have to > modify genemit.c myself. I don't know what you suppose to accomplish with this snide. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (5 preceding siblings ...) 2012-08-05 12:04 ` steven at gcc dot gnu.org @ 2012-08-05 12:21 ` jason.vas.dias at gmail dot com 2012-08-05 12:28 ` wbrana at gmail dot com ` (33 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 12:21 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #7 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 12:21:10 UTC --- Thanks for your response ! I think the cc1 process is somehow operating in slow motion, even though I've pinned the CPU frequency to 1.8 GHz (it will crash if I don't reduce it soon - so this is not a "slow machine" issue!) . cc1 is writing about one line every 2 minutes to its assembler output file: ... 12:10:14 write(3, "3\n.L2088:\n\tmovq\t(%rbx), %rdi\n\tca"..., 4096) = 4096 ... 12:12:24 write(3, "%edi\n\tmovq\t32(%rbx), %rbx\n\tcall\t"..., 4096) = 4096 ... I think this is because it has to hold a huge chunk of "contiguous" memory : $ ps -o 'vsz rss %mem' -p 3863 VSZ RSS %MEM 258444 125752 7.3 So it is trying to hold @1.25GB of contiguous RAM. (my machine has 2GB). These memory requirements are solely due to the size of the .c file (1.8MB) . Why can't they be reduced somewhat? ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (6 preceding siblings ...) 2012-08-05 12:21 ` jason.vas.dias at gmail dot com @ 2012-08-05 12:28 ` wbrana at gmail dot com 2012-08-05 12:34 ` steven at gcc dot gnu.org ` (32 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: wbrana at gmail dot com @ 2012-08-05 12:28 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #8 from wbrana <wbrana at gmail dot com> 2012-08-05 12:27:52 UTC --- 2 GB RAM isn't enough. It isn't good idea to use x86_64 with 2 GB RAM. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (7 preceding siblings ...) 2012-08-05 12:28 ` wbrana at gmail dot com @ 2012-08-05 12:34 ` steven at gcc dot gnu.org 2012-08-05 12:37 ` steven at gcc dot gnu.org ` (31 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 12:34 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #9 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 12:33:56 UTC --- (In reply to comment #7) > cc1 is writing about one line every 2 minutes to its assembler output file: If you've really configured with --enable-stage1-checking=all, you've enabled some checks that can cause this kind of slowdown. One of these checks is an internal memory integrity check on the garbage collector. I suspect that what you're seeing, is a garbage collection attempt between every insn emitted. That would mark-and-sweeps all memory between each assembler output line. All forms of --enable-checking=all are really for debugging purposes only, and even then only for cases where GDB doesn't help (Heisenbug-like issues, strange memory corruption problems, etc.). GCC 4.7.1 is a release compiler, you shouldn't have to configure with any checking flags enabled (configure will default to --enable-checking=release). In other words, if this problem is what I suspect, then this bug is one of those "Doctor it hurts if I ..." problems. ;-) Can you please try without -enable-stage1-checking=all? ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (8 preceding siblings ...) 2012-08-05 12:34 ` steven at gcc dot gnu.org @ 2012-08-05 12:37 ` steven at gcc dot gnu.org 2012-08-05 13:16 ` jason.vas.dias at gmail dot com ` (30 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 12:37 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #10 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 12:37:28 UTC --- (In reply to comment #7) > These memory requirements are solely due to the size of the .c file (1.8MB) . This is indeed excessive, we'll have to look into this. If you have preprocessed source and the compilation flags, can you please attach it? Or if you feel like helping out today, try to do a (non-bootstrap) build with --enable-gather-statistics, compile the file, and report back the resulting time and memory reports. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (9 preceding siblings ...) 2012-08-05 12:37 ` steven at gcc dot gnu.org @ 2012-08-05 13:16 ` jason.vas.dias at gmail dot com 2012-08-05 13:31 ` wbrana at gmail dot com ` (29 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 13:16 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #11 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 13:16:03 UTC --- Thanks for the responses - I will try again with '--enable-checking=release'. But, I still don't think this bug is a "non-issue" - here's why: RE: wbrana 2012-08-05 12:27:52 UTC > 2 GB RAM isn't enough. > It isn't good idea to use x86_64 with 2 GB RAM. Sorry, but gcc shouldn't be enforcing this on us - I thought it was supposed to be capable of being an embedded systems compiler - are you saying gcc cannot be compiled or run on any embedded system with less than 2GB RAM ? Surely not! RE: [reply] [-] Comment 9 Steven Bosscher 2012-08-05 12:33:56 UTC Thanks for your response Steven! > (In reply to comment #7) >> cc1 is writing about one line every 2 minutes to its assembler output file: > If you've really configured with --enable-stage1-checking=all, you've enabled .. > All forms of --enable-checking=all are really for debugging purposes only ... > Can you please try without -enable-stage1-checking=all? Fair enough, OK, I will. But I'd still like some kind of answer - why MUST insn-emit.c be so large ? The answer "compiling lots of small .c files is slower that one large one" is demonstrably false on my machine and on many other machines with not much RAM I suspect, and must be qualified with "if you have a platform with X RAM and X CPU speed" . If the gcc build scripts detect they are running on a platform with less than 4GB of RAM, say, they could decide to split insn-emit.c . Why is it so inconceivable that they might in future do something like this ? ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (10 preceding siblings ...) 2012-08-05 13:16 ` jason.vas.dias at gmail dot com @ 2012-08-05 13:31 ` wbrana at gmail dot com 2012-08-05 13:43 ` jason.vas.dias at gmail dot com ` (28 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: wbrana at gmail dot com @ 2012-08-05 13:31 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #12 from wbrana <wbrana at gmail dot com> 2012-08-05 13:31:28 UTC --- embedded systems compiler doesn't mean you can run gcc on embedded system, but you can cross compile for embedded system. Average user doesn't build or use compiler. It is only done by developers which have modern PC which means 8 GB RAM. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (11 preceding siblings ...) 2012-08-05 13:31 ` wbrana at gmail dot com @ 2012-08-05 13:43 ` jason.vas.dias at gmail dot com 2012-08-05 13:46 ` jason.vas.dias at gmail dot com ` (27 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 13:43 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #13 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 13:43:21 UTC --- RE: > Steven Bosscher 2012-08-05 12:37:28 UTC \ (In reply to comment #7) >> These memory requirements are solely due to the size of the .c file (1.8MB) . > > This is indeed excessive, we'll have to look into this. If you have > preprocessed source and the compilation flags, can you please attach it? Or if > you feel like helping out today, try to do a (non-bootstrap) build with > --enable-gather-statistics, compile the file, and report back the resulting > time and memory reports. compilation flags given in previous comment: $ tr '\0' ' ' < /proc/3863/cmdline /mnt/sda3/gcc/./prev-gcc/cc1 -quiet -I . -I . -I /usr/build2/gcc/gcc-4.7.1/gcc -I /usr/build2/gcc/gcc-4.7.1/gcc/. -I /usr/build2/gcc/gcc-4.7.1/gcc/../include -I /usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include -I /usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber -I /usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I ../libdecnumber -iprefix /mnt/sda3/gcc/prev-gcc/../lib64/gcc/x86_64-pc-linux-gnu/4.7.1/ -isystem /mnt/sda3/gcc/./prev-gcc/include -isystem /mnt/sda3/gcc/./prev-gcc/include-fixed -D IN_GCC -D HAVE_CONFIG_H -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include insn-emit.c -quiet -dumpbase insn-emit.c -mtune=k8 -march=x86-64 -auxbase-strip insn-emit.o -g -gtoggle -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -o /tmp/ccgsb5Pk.s Sorry I for the word-wrap in your website form - in my day, bugzilla / firefox didn't do that. Adding pre-processed source 'xz --compress -9' insn-emit.i.xz file of the PRE-PROCESSED C source - you mean the output of the previous command with '-o /tmp/ccgsb5Pk.s' replaced by '-E -o insn-emit.i' ? So the config options I'll now use (for my initial "C"-only build, which enables ONLY the "C" language, sufficient ONLY to pass the "C"-only test suite, and to recompile binutils, gmp, mpfr, mpc, and ppl + cloog for "C" only, making sure they pass their test suites, before rebuilding glibc and then GCC + G++ with '--enable-languages=all' and the new glibc, binutils, gmp, mpfr, mpc + ppl/cloog built with the C-only compiler. (this is the way I've always done it) : $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 \ --enable-multilib --with-cpu-32=i686 --with-cpu-64=k8 \ --enable-version-specific-runtime-libs \ --enable-languages=c \ --enable-bootstrap \ --enable-stage1-languages=c \ --disable-build-with-cxx --disable-build-poststage1-with-cxx \ --enable-checking=release --enable-stage1-checking=release \ --enable-gather-statistics \ --enable-targets=all \ --enable-threads=posix --enable-tls \ --enable-lto --enable-shared \ --with-build-time-tools=/usr/bin \ --with-ld=/usr/bin/ld --with-gnu-ld \ --with-as=/usr/bin/as --with-gnu-as \ --with-system-zlib --without-included-gettext --enable-serial-configure \ --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu ?? I'll post the statistics files gathered after the build - where are they ? If any suggested changes, please advise soon. Thanks & Regards, Jason Vas Dias ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (12 preceding siblings ...) 2012-08-05 13:43 ` jason.vas.dias at gmail dot com @ 2012-08-05 13:46 ` jason.vas.dias at gmail dot com 2012-08-05 13:51 ` jason.vas.dias at gmail dot com ` (26 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 13:46 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #14 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 13:46:26 UTC --- $ time /mnt/sda3/gcc/./prev-gcc/xgcc -B/mnt/sda3/gcc/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -g -O2 -gtoggle -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/usr/build2/gcc/gcc-4.7.1/gcc -I/usr/build2/gcc/gcc-4.7.1/gcc/. -I/usr/build2/gcc/gcc-4.7.1/gcc/../include -I/usr/build2/gcc/gcc-4.7.1/gcc/../libcpp/include -I/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber -I/usr/build2/gcc/gcc-4.7.1/gcc/../libdecnumber/bid -I../libdecnumber insn-emit.c -E insn-emit.c > insn-emit.i real 0m6.243s user 0m5.862s sys 0m0.284s now attaching insn-emit.i.xz ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (13 preceding siblings ...) 2012-08-05 13:46 ` jason.vas.dias at gmail dot com @ 2012-08-05 13:51 ` jason.vas.dias at gmail dot com 2012-08-05 13:54 ` steven at gcc dot gnu.org ` (25 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 13:51 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #15 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 13:51:27 UTC --- Created attachment 27939 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27939 pre-processed "C" from previous comment command $ xz --uncompress < insn-emit.i.xz > insn-emit.i # pre-processed "C" from previous comment command ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (14 preceding siblings ...) 2012-08-05 13:51 ` jason.vas.dias at gmail dot com @ 2012-08-05 13:54 ` steven at gcc dot gnu.org 2012-08-05 13:55 ` steven at gcc dot gnu.org ` (24 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 13:54 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #16 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 13:54:30 UTC --- > $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib64 \ > --enable-multilib --with-cpu-32=i686 --with-cpu-64=k8 \ > --enable-version-specific-runtime-libs \ > --enable-languages=c \ > --enable-bootstrap \ --disable-bootstrap if you're doing > --enable-gather-statistics \ ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (15 preceding siblings ...) 2012-08-05 13:54 ` steven at gcc dot gnu.org @ 2012-08-05 13:55 ` steven at gcc dot gnu.org 2012-08-05 14:12 ` wbrana at gmail dot com ` (23 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 13:55 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #17 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 13:55:43 UTC --- (In reply to comment #12) > Average user doesn't build or use compiler. It is only done by developers which > have modern PC which means 8 GB RAM. Sorry, but this is just rubbish. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (16 preceding siblings ...) 2012-08-05 13:55 ` steven at gcc dot gnu.org @ 2012-08-05 14:12 ` wbrana at gmail dot com 2012-08-05 14:13 ` schwab@linux-m68k.org ` (22 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: wbrana at gmail dot com @ 2012-08-05 14:12 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #18 from wbrana <wbrana at gmail dot com> 2012-08-05 14:11:37 UTC --- (In reply to comment #17) > Sorry, but this is just rubbish. You didn't confute my statements. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (17 preceding siblings ...) 2012-08-05 14:12 ` wbrana at gmail dot com @ 2012-08-05 14:13 ` schwab@linux-m68k.org 2012-08-05 18:10 ` jason.vas.dias at gmail dot com ` (21 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: schwab@linux-m68k.org @ 2012-08-05 14:13 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #19 from Andreas Schwab <schwab@linux-m68k.org> 2012-08-05 14:13:32 UTC --- GCC can comfortably be built with just 1GB of memory. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (18 preceding siblings ...) 2012-08-05 14:13 ` schwab@linux-m68k.org @ 2012-08-05 18:10 ` jason.vas.dias at gmail dot com 2012-08-05 18:39 ` steven at gcc dot gnu.org ` (20 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 18:10 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #20 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 18:10:24 UTC --- RE: > --disable-bootstrap if you're doing --enable-gather-statistics but for me this defeats the whole purpose of building a "C-only" bootstrap compiler. I see no point in proceeding to build C++ , Java, Obj-C et al until binutils, glibc, gmp, mpfr, mpc, ppl/cloog, gettext, zlib et al have been re-built and tested using the pure-c compiler ; to me, the first thing I'd do with a default 'configure && make' GCC with --enable-languages=all is re-compile binutils + glibc et al and then repeat the GCC build - so why use --enable-languages=all until GCC's dependencies have been rebuilt using the new GCC ? Anyway, my laptop is in the cooler now, producing around 1 PAGE of assembler every two minutes (sorry, strace was truncating) , it has produced around 2MB of assembler so far, so I might as well let it continue for the next week or so until it finishes ... thanks for all the responses explaining why this takes so long with --enable-checking=all - I'll remember not to use this again. Couldn't there be a new "enable all checks except garbage collection checks" option ? Thanks & Regards, Jason ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (19 preceding siblings ...) 2012-08-05 18:10 ` jason.vas.dias at gmail dot com @ 2012-08-05 18:39 ` steven at gcc dot gnu.org 2012-08-05 19:49 ` jason.vas.dias at gmail dot com ` (19 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 18:39 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Steven Bosscher <steven at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID --- Comment #21 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 18:39:39 UTC --- (In reply to comment #20) > RE: > --disable-bootstrap if you're doing --enable-gather-statistics You're making no sense to me at all. Have you even read the installation documentation (http://gcc.gnu.org/install/)? You're using really unusual configuration options. If you want a C-only compiler then you should just configure with "--enable-languages=c" only, no other configuration options needed. You don't even have to do "make bootstrap" because it's the default, i.e. the compiler always bootstraps itself unless you configure with --disable-bootstrap. What I asked for, was --enable-gather-statistics output for your compilation of insn-emit.c, but you don't want to gather statistics with a bootstrapped compiler (like --enable-checking=all, --enable-gather-statistics is a debug option). > Couldn't there be a new "enable all checks except garbage collection checks" > option ? No. You can pick individual checks (RTFM) but there is no option to enable all checking except GC. One page every two minutes is still unbelievable slow. GCC 4.7.1. on x86_64 has been built by thousands without any problem. I tried your pre-processed source and peak memory was 250MB. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (20 preceding siblings ...) 2012-08-05 18:39 ` steven at gcc dot gnu.org @ 2012-08-05 19:49 ` jason.vas.dias at gmail dot com 2012-08-05 19:52 ` jason.vas.dias at gmail dot com ` (18 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 19:49 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #22 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 19:48:45 UTC --- RE: > If you want a C-only compiler then you should just configure with > "--enable-languages=c" only of course, I tried that first, but that is no longer possible with gcc-4.7.1+ . My post to gcc-bugs about this issue was bounced: Jonathan Wakely jwakely.gcc@gmail.com Jul 8 Reply to me, gcc-bugs Hi, The gcc-bugs mailing list is for automated emails from our Bugzilla database. Your question is not about a bug, so would be more appropriate on the gcc-help mailing list. The answer to your question is that GCC itself is now built using a C++ compiler, so it needs to build the C++ compiler to build itself, see http://gcc.gnu.org/install/configure.html --enable-build-poststage1-with-cxx When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler rather than a C compiler. Stage 1 is still built with a C compiler. This is enabled by default and may be disabled using --disable-build-poststage1-with-cxx. Re: gcc-4.7.1 build system question : why is "make bootstrap" with configure option '--enable-languages=c' building the C++ compiler ? GCC x Jason Vas Dias Jul 8 Reply to gcc-bugs OK, so I'm reconfiguring with : --enable-languages=c --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-stage1-checking=all --enable-stage1-languages=c but why should I have to ? Shouldn't "--enable-languages=c" be enough to disable building the C++ compiler and libstdc++ ? Thanks & Regards, Jason On Sun, Jul 8, 2012 at 4:06 PM, Jason Vas Dias <jason.vas.dias@gmail.com> wrote: > Hi - I've been regularly building gcc for nearly two decades, and now > attempting to build a bootstrap > "C" only gcc-4.7.1 sufficient only to build binutils (my initial first > step is always to rebuild binutils > with the bootstrap "C" only compiler before doing a complete "make" > with "--enable-languages=all" - > a shame that support for configuring and building binutils along with > gcc has been withdrawn , > so now I attempt to rebuild binutils separately with the "C" only > bootstrap compiler) . > > Now this doesn't work - building "C"-only ( --enable-languages=c ) > bootstrap fails building "C++" : > > /mnt/sda3/gcc/./prev-gcc/g++ -B/mnt/sda3/gcc/./prev-gcc/ > -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ > -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -B/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu > -I/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/include > -I/usr/build2/gcc/gcc-4.7.1/libstdc++-v3/libsupc++ > -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs > -L/mnt/sda3/gcc/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs > -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c-lang.o > c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o > c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o > c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o > c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o > c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o > c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o > c-family/c-semantics.o c-family/c-ada-spec.o i386-c.o default-c.o \ > cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a > ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a > ../libcpp/libcpp.a ../libiberty/libiberty.a > ../libdecnumber/libdecnumber.a -lcloog -lppl_c -lppl -lpwl -lgmpxx > -lmpc -lmpfr -lgmp -rdynamic -ldl -lz > lto/lto.o: In function `lto_ft_typed(tree_node*)': > lto.c:(.text+0x326): undefined reference to `tree_code_type' > lto/lto.o: In function `lto_ft_common(tree_node*)': > lto.c:(.text+0x38b): undefined reference to `tree_code_type' > lto/lto.o: In function `lto_ft_decl_common(tree_node*)': > lto.c:(.text+0x3fb): undefined reference to `tree_code_type' > lto.c:(.text+0x432): undefined reference to `tree_code_type' > lto.c:(.text+0x469): undefined reference to `tree_code_type' > lto/lto.o:lto.c:(.text+0x49e): more undefined references to > `tree_code_type' follow > > Boy, does it really mean it when it says "more undefined references to > `tree_code_type' follow" : > > $ grep 'undefined reference' make.bootstrap-cntnd.log | wc -l > 18127 > > My config.log command : > > > generated by GNU Autoconf 2.64. Invocation command line was > > $ /usr/build2/gcc/gcc-4.7.1/configure --prefix=/usr > --libdir=/usr/lib64 --with-cpu-32=i686 --with-cpu-64=k8 > --enable-languages=c --enable-targets=all --enable-multi > lib --enable-threads=posix --enable-tls --enable-lto --enable-shared > --enable-checking=release --with-build-time-tools=/usr/bin > --with-ld=/usr/bin/ld --with-gnu-ld -- > with-as=/usr/bin/as --with-gnu-as > --enable-version-specific-runtime-libs --with-system-zlib > --without-included-gettext --enable-bootstrap > --enable-serial-configure -- > host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu > > ## --------- ## > ## Platform. ## > ## --------- ## > > hostname = jvdspc > uname -m = x86_64 > uname -r = 3.4.4-jvd+ > uname -s = Linux > uname -v = #4 SMP Fri Jul 6 20:19:44 GMT 2012 > > /usr/bin/uname -p = unknown > /bin/uname -X = unknown > > /bin/arch = x86_64 > /usr/bin/arch -k = unknown > /usr/convex/getsysinfo = unknown > /usr/bin/hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > I configured with above command and did: > > $ make -j2 bootstrap 2>&1 | tee make.bootstrap.log > > This built fine overnight , and when I woke up in the morning the > machine was in a hard lock-up state > (overheating - I'm also investigating a kernel bug on this issue). > > The build had created the "stage_final" file and a working prev-gcc/xgcc - > Can anyone suggest why making a "bootstrap" "C" "--enable-languages=c" > compiler should then > go on to build "C++" ? > > I'm pretty sure the above error would not have occurred without the > kernel lock-up and interruption, > but nevertheless, I didn't ask the gcc build system to build C++ yet, > so why did it do so ? > > Any ideas / comments would be much appreciated , > Jason Vas Dias (a Software Engineer) <jason.vas.dias@gmail.com> So one can no longer build gcc without building c++ and libstdc++ without the non-standard options you mention. There really is no need for comments such as these : > Have you even read the installation > documentation (http://gcc.gnu.org/install/)? if you trawl the lists you'd see I've been posting on various gcc issues once in a while when I come across them since @ 1988 - yes, I have read the documentation, which still stands in need of updating about being unable to build c without also building c++ without '--disable-build-with-cxx --disable-build-poststage1-with-cxx' . And I hope I'm going to find out that --enable-version-specific-runtime-libs is now working as expected ! ie. not creating multiple copies of libgcc_s.so in different places. :-) These are only niggles, really, after all - I'm only trying help iron them out! I will build with --enable-gather-statistics once my initial "pure-c" compiler builds, has passed the "C" test suite, and has built binutils, glibc, gmp, et al., and then post the results. I'll bet they'll show that it still takes nearly an hour to generate the assembler for insn-emit.c . All I'm suggesting is perhaps on machines with less than Xgb RAM the build scripts might split this file up , and maybe even generate different sections in parallel - then the insn-emit.c build should take no more than 10 mins or so and maybe even '--enable-checking=all' builds might become feasible. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (21 preceding siblings ...) 2012-08-05 19:49 ` jason.vas.dias at gmail dot com @ 2012-08-05 19:52 ` jason.vas.dias at gmail dot com 2012-08-05 20:10 ` jason.vas.dias at gmail dot com ` (17 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 19:52 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #23 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 19:51:56 UTC --- Yes, I was wondering how long it would take to close this bug as INVALID, which seems to be the standard response to uncomfortable bug reports these days. It turned out to be less time than gcc is taking to generate the assembler for insn-emit.c :-) ! ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (22 preceding siblings ...) 2012-08-05 19:52 ` jason.vas.dias at gmail dot com @ 2012-08-05 20:10 ` jason.vas.dias at gmail dot com 2012-08-05 20:17 ` steven at gcc dot gnu.org ` (16 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 20:10 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #24 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 20:10:36 UTC --- $ ps -lp 3863 F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 0 R 0 3863 3862 99 80 0 - 64611 - pts/5 1-05:55:03 cc1 ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (23 preceding siblings ...) 2012-08-05 20:10 ` jason.vas.dias at gmail dot com @ 2012-08-05 20:17 ` steven at gcc dot gnu.org 2012-08-05 20:58 ` jason.vas.dias at gmail dot com ` (15 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 20:17 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Steven Bosscher <steven at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |WONTFIX --- Comment #25 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 20:16:48 UTC --- > Yes, I was wondering how long it would take to close this bug as INVALID, > which seems to be the standard response to uncomfortable bug reports these > days. There is nothing "uncomfortable" about this bug. You're just trying to do something you're not supposed to do. You should not bootstrap with all checking enabled. Resolution changed to WONTFIX, perhaps that doesn't hurt your feelings as much. > It turned out to be less time than gcc is taking to generate the assembler for > insn-emit.c :-) ! I've done 17 bootstraps with all languages enabled on x86_64 since this morning... ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (24 preceding siblings ...) 2012-08-05 20:17 ` steven at gcc dot gnu.org @ 2012-08-05 20:58 ` jason.vas.dias at gmail dot com 2012-08-05 21:05 ` steven at gcc dot gnu.org ` (14 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: jason.vas.dias at gmail dot com @ 2012-08-05 20:58 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #26 from Jason Vas Dias <jason.vas.dias at gmail dot com> 2012-08-05 20:57:59 UTC --- Well, when I read on the documentation page http://gcc.gnu.org/install/configure.html --enable-build-with-cxx Build GCC using a C++ compiler rather than a C compiler. This is an experimental option which may become the default in a later release. --enable-bootstrap In special cases, you may want to perform a 3-stage build even if the target and host triplets are different. This is possible when the host can run code compiled for the target (e.g. host is i686-linux, target is i486-linux). Starting from GCC 4.2, to do this you have to configure explicitly with --enable-bootstrap. --enable-checking --enable-checking=list When you specify this option, the compiler is built to perform internal consistency checks of the requested complexity. This does not change the generated code, but adds error checking within the compiler. This will slow down the compiler and may only work properly if you are building the compiler with GCC. This is `yes' by default when building from SVN or snapshots, but `release' for releases. The default for building the stage1 compiler is `yes'. More control over the checks may be had by specifying list. The categories of checks available are `yes' (most common checks `assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all), `all' (all but `valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as `no'). Individual checks can be enabled with these flags `assert', `df', `fold', `gc', `gcac' `misc', `rtl', `rtlflag', `runtime', `tree', and `valgrind'. The `valgrind' check requires the external valgrind simulator, available from http://valgrind.org/. The `df', `rtl', `gcac' and `valgrind' checks are very expensive. To disable all checking, `--disable-checking' or `--enable-checking=none' must be explicitly requested. Disabling assertions will make the compiler and runtime slightly faster but increase the risk of undetected internal errors causing wrong code to be generated. Where does it say I cannot build "C" and not "C++" without specifying --enable-languages=c --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-stage1-languages=c which is in fact the case ? Where does it say that users should never use "--enable-checking=all" with "--enable-bootstrap" ? And what has any of this to do with the simple question posed in the title of this bug report : why can't insn-emit.c be split ? ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (25 preceding siblings ...) 2012-08-05 20:58 ` jason.vas.dias at gmail dot com @ 2012-08-05 21:05 ` steven at gcc dot gnu.org 2012-08-06 8:43 ` rguenth at gcc dot gnu.org ` (13 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-05 21:05 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #27 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-05 21:05:41 UTC --- (In reply to comment #26) > And what has any of this to do with the simple question posed in the title > of this bug report : why can't insn-emit.c be split ? It could be split up. But I wouldn't count on anyone doing the work. Patches welcome, of course... Actually, I'm more interested in seeing if insn-emit.c can be reduced in size by avoiding duplicate functions (see e.g. gen_swapdi/gen_swapsi/gen_swapxf for x86_64 for a simple case of identical functions). ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (26 preceding siblings ...) 2012-08-05 21:05 ` steven at gcc dot gnu.org @ 2012-08-06 8:43 ` rguenth at gcc dot gnu.org 2012-08-06 9:11 ` steven at gcc dot gnu.org ` (12 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: rguenth at gcc dot gnu.org @ 2012-08-06 8:43 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #28 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-06 08:42:57 UTC --- (In reply to comment #26) > Well, when I read on the documentation page > > http://gcc.gnu.org/install/configure.html > > > --enable-build-with-cxx > Build GCC using a C++ compiler rather than a C compiler. This is an > experimental option which may become the default in a later release. > > > --enable-bootstrap > In special cases, you may want to perform a 3-stage build even if the > target and host triplets are different. This is possible when the host can run > code compiled for the target (e.g. host is i686-linux, target is i486-linux). > Starting from GCC 4.2, to do this you have to configure explicitly with > --enable-bootstrap. > > > --enable-checking > --enable-checking=list > When you specify this option, the compiler is built to perform internal > consistency checks of the requested complexity. This does not change the > generated code, but adds error checking within the compiler. This will slow > down the compiler and may only work properly if you are building the compiler > with GCC. This is `yes' by default when building from SVN or snapshots, but > `release' for releases. The default for building the stage1 compiler is `yes'. > More control over the checks may be had by specifying list. The categories of > checks available are `yes' (most common checks > `assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all), `all' (all but > `valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as > `no'). Individual checks can be enabled with these flags `assert', `df', > `fold', `gc', `gcac' `misc', `rtl', `rtlflag', `runtime', `tree', and > `valgrind'. > > The `valgrind' check requires the external valgrind simulator, available > from http://valgrind.org/. The `df', `rtl', `gcac' and `valgrind' checks are > very expensive. To disable all checking, `--disable-checking' or > `--enable-checking=none' must be explicitly requested. Disabling assertions > will make the compiler and runtime slightly faster but increase the risk of > undetected internal errors causing wrong code to be generated. > > > > > > > Where does it say I cannot build "C" and not "C++" without specifying > > --enable-languages=c --disable-build-with-cxx > --disable-build-poststage1-with-cxx --enable-stage1-languages=c > > which is in fact the case ? > > Where does it say that users should never use "--enable-checking=all" > with "--enable-bootstrap" ? Well, the docs don't say that you need any of --enable-checking to build GCC. And --enable-checking=all does exactly what is documented ;) For releases the default configuration is --enable-checking=release --enbale-stage1-checking=yes (to check the compiler but not slow down the final created compiler). So, if you don't know what you are doing just stick with the defaults ;) > And what has any of this to do with the simple question posed in the title > of this bug report : why can't insn-emit.c be split ? ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (27 preceding siblings ...) 2012-08-06 8:43 ` rguenth at gcc dot gnu.org @ 2012-08-06 9:11 ` steven at gcc dot gnu.org 2012-08-06 10:49 ` steven at gcc dot gnu.org ` (11 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-06 9:11 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #29 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-06 09:10:49 UTC --- (In reply to comment #27) > Actually, I'm more interested in seeing if insn-emit.c can be reduced in size > by avoiding duplicate functions (see e.g. gen_swapdi/gen_swapsi/gen_swapxf for > x86_64 for a simple case of identical functions). This doesn't seem to be a winning opportunity. It should be possible to split insn-emit.c into separate files for define_insns, splitters, expanders, and peephole handlers, but that, too, doesn't seem to be a win because the vast majority of patterns are insns. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (28 preceding siblings ...) 2012-08-06 9:11 ` steven at gcc dot gnu.org @ 2012-08-06 10:49 ` steven at gcc dot gnu.org 2023-07-06 10:49 ` mmokrejs at gmail dot com ` (10 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: steven at gcc dot gnu.org @ 2012-08-06 10:49 UTC (permalink / raw) To: gcc-bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #30 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-06 10:49:03 UTC --- Created attachment 27950 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27950 Split insn-emit.c into four separate files Untested, etc., and doesn't apply to GCC 4.7 because it doesn't have the patch to split insn-attrtab.c. But it shows what could be done to split insn-emit.c. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (29 preceding siblings ...) 2012-08-06 10:49 ` steven at gcc dot gnu.org @ 2023-07-06 10:49 ` mmokrejs at gmail dot com 2023-07-07 11:29 ` sjames at gcc dot gnu.org ` (9 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: mmokrejs at gmail dot com @ 2023-07-06 10:49 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 mmokrejs at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mmokrejs at gmail dot com --- Comment #31 from mmokrejs at gmail dot com --- Still happens with gcc-12.3.1_p20230526 on Gentoo Linux on a 2 GB RAM virtual server running out of memory due to -O2 and triggers Oom killer. I tried -O1 but it was not enough. However, -O0 worked for me. The problem is that the bootstrapping check failed, probably because of some differences. /var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/./prev-gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -isystem /var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -isystem /var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -isystem /var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/libstdc++-v3/libsupc++ -L/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -fno-PIE -m64 -pipe -march=x86-64 -O0 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/. -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../include -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libcody -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libdecnumber/bid -I../libdecnumber -I/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/gcc-12-20230526/gcc/../libbacktrace -o insn-emit.o -MT insn-emit.o -MMD -MP -MF ./.deps/insn-emit.TPo insn-emit.cc make[3]: Entering directory '/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build' rm -f stage_current make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/insn-emit.o differs make[2]: *** [Makefile:24126: compare] Error 1 make[2]: Leaving directory '/var/tmp/portage/sys-devel/gcc-12.3.1_p20230526/work/build' ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug c/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (30 preceding siblings ...) 2023-07-06 10:49 ` mmokrejs at gmail dot com @ 2023-07-07 11:29 ` sjames at gcc dot gnu.org 2023-07-07 11:39 ` [Bug bootstrap/54179] " tnfchris at gcc dot gnu.org ` (8 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: sjames at gcc dot gnu.org @ 2023-07-07 11:29 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Sam James <sjames at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |--- Status|RESOLVED |UNCONFIRMED CC| |tnfchris at gcc dot gnu.org --- Comment #32 from Sam James <sjames at gcc dot gnu.org> --- I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about this, apologies if I'm misremembering. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (31 preceding siblings ...) 2023-07-07 11:29 ` sjames at gcc dot gnu.org @ 2023-07-07 11:39 ` tnfchris at gcc dot gnu.org 2023-07-07 12:47 ` mmokrejs at gmail dot com ` (7 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: tnfchris at gcc dot gnu.org @ 2023-07-07 11:39 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #33 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to Sam James from comment #32) > I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about > this, apologies if I'm misremembering. Hello, yes I have a patch locally that I need to finish (there's a lot of gen- machinery). I'll try to get it upstream soon :) ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (32 preceding siblings ...) 2023-07-07 11:39 ` [Bug bootstrap/54179] " tnfchris at gcc dot gnu.org @ 2023-07-07 12:47 ` mmokrejs at gmail dot com 2023-10-31 12:48 ` sjames at gcc dot gnu.org ` (6 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: mmokrejs at gmail dot com @ 2023-07-07 12:47 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #34 from mmokrejs at gmail dot com --- Thank you all. Just to clarify https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179#c31 , I did not show the Oom error itself nor the cmd killed dut to that but you can see details at https://bugs.gentoo.org/show_bug.cgi?id=909766 . I shouldn't have run just "make" but properly letting bootsrap procedure to continue, which I do not know how to. And that triggered the comparison error I assume. I used to have only 1GB RAM available in the virtual machine btw. and I always had to get around somehow the bootstrapping issue. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (33 preceding siblings ...) 2023-07-07 12:47 ` mmokrejs at gmail dot com @ 2023-10-31 12:48 ` sjames at gcc dot gnu.org 2023-11-13 13:07 ` brjd_epdjq36 at kygur dot com ` (5 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: sjames at gcc dot gnu.org @ 2023-10-31 12:48 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Sam James <sjames at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #35 from Sam James <sjames at gcc dot gnu.org> --- Done in commit 184378027e92f51e02d3649e0ca523f487fd2810 Author: Robin Dapp <rdapp@ventanamicro.com> Date: Thu Oct 12 11:23:26 2023 +0200 genemit: Split insn-emit.cc into several partitions. On riscv insn-emit.cc has grown to over 1.2 mio lines of code and compiling it takes considerable time. Therefore, this patch adjust genemit to create several partitions (insn-emit-1.cc to insn-emit-n.cc). The available patterns are written to the given files in a sequential fashion. Similar to match.pd a configure option --with-emitinsn-partitions=num is introduced that makes the number of partition configurable. gcc/ChangeLog: PR bootstrap/84402 PR target/111600 * Makefile.in: Handle split insn-emit.cc. * configure: Regenerate. * configure.ac: Add --with-insnemit-partitions. * genemit.cc (output_peephole2_scratches): Print to file instead of stdout. (print_code): Ditto. (gen_rtx_scratch): Ditto. (gen_exp): Ditto. (gen_emit_seq): Ditto. (emit_c_code): Ditto. (gen_insn): Ditto. (gen_expand): Ditto. (gen_split): Ditto. (output_add_clobbers): Ditto. (output_added_clobbers_hard_reg_p): Ditto. (print_overload_arguments): Ditto. (print_overload_test): Ditto. (handle_overloaded_code_for): Ditto. (handle_overloaded_gen): Ditto. (print_header): New function. (handle_arg): New function. (main): Split output into 10 files. * gensupport.cc (count_patterns): New function. * gensupport.h (count_patterns): Define. * read-md.cc (md_reader::print_md_ptr_loc): Add file argument. * read-md.h (class md_reader): Change definition. for 14. 14 will therefore have both split insn-emit as well as *-match from tamar earlier in the year, which makes life a lot easier with constrained resources. I've also backported it downstream as well. I don't think anyone plans on doing it upstream. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (34 preceding siblings ...) 2023-10-31 12:48 ` sjames at gcc dot gnu.org @ 2023-11-13 13:07 ` brjd_epdjq36 at kygur dot com 2023-11-13 15:03 ` xry111 at gcc dot gnu.org ` (4 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: brjd_epdjq36 at kygur dot com @ 2023-11-13 13:07 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #36 from Brjd <brjd_epdjq36 at kygur dot com> --- I got memory troubles with insn-recog.cc and gimple-match.cc too. Please correct them for gcc 10-13 in the their last .5 releases, so that we can bootstrap. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (35 preceding siblings ...) 2023-11-13 13:07 ` brjd_epdjq36 at kygur dot com @ 2023-11-13 15:03 ` xry111 at gcc dot gnu.org 2023-11-13 15:12 ` brjd_epdjq36 at kygur dot com ` (3 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: xry111 at gcc dot gnu.org @ 2023-11-13 15:03 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Xi Ruoyao <xry111 at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xry111 at gcc dot gnu.org --- Comment #37 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to Brjd from comment #36) > I got memory troubles with insn-recog.cc and gimple-match.cc too. Please > correct them for gcc 10-13 in the their last .5 releases, so that we can > bootstrap. No, such a major change is never a candidate for backport. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (36 preceding siblings ...) 2023-11-13 15:03 ` xry111 at gcc dot gnu.org @ 2023-11-13 15:12 ` brjd_epdjq36 at kygur dot com 2024-05-11 12:08 ` brjd_epdjq36 at kygur dot com ` (2 subsequent siblings) 40 siblings, 0 replies; 42+ messages in thread From: brjd_epdjq36 at kygur dot com @ 2023-11-13 15:12 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Brjd <brjd_epdjq36 at kygur dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brjd_epdjq36 at kygur dot com --- Comment #38 from Brjd <brjd_epdjq36 at kygur dot com> --- It is good for 14 but you agree that these files become really huge in size and it is very difficult to open them. 5-10 MB is crazy:) ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (37 preceding siblings ...) 2023-11-13 15:12 ` brjd_epdjq36 at kygur dot com @ 2024-05-11 12:08 ` brjd_epdjq36 at kygur dot com 2024-05-12 4:29 ` sjames at gcc dot gnu.org 2024-05-12 10:19 ` brjd_epdjq36 at kygur dot com 40 siblings, 0 replies; 42+ messages in thread From: brjd_epdjq36 at kygur dot com @ 2024-05-11 12:08 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #39 from Brjd <brjd_epdjq36 at kygur dot com> --- Let me share what I notice in 14.1. Significant improvement in insn-emit.cc and gimple-match.cc. This is good news. Insn-recog.cc is much the same and needs ~ 1.6 GiB RAM. Yet, another possible issue in the future might be gcc/genautomata.cc or insn-conditions.md > tmp-automata.cc where RAM reaches 1.8 GiB. The rest of the build is pretty nice at just 500-600 MiB. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (38 preceding siblings ...) 2024-05-11 12:08 ` brjd_epdjq36 at kygur dot com @ 2024-05-12 4:29 ` sjames at gcc dot gnu.org 2024-05-12 10:19 ` brjd_epdjq36 at kygur dot com 40 siblings, 0 replies; 42+ messages in thread From: sjames at gcc dot gnu.org @ 2024-05-12 4:29 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #40 from Sam James <sjames at gcc dot gnu.org> --- That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [Bug bootstrap/54179] please split insn-emit.c ! 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com ` (39 preceding siblings ...) 2024-05-12 4:29 ` sjames at gcc dot gnu.org @ 2024-05-12 10:19 ` brjd_epdjq36 at kygur dot com 40 siblings, 0 replies; 42+ messages in thread From: brjd_epdjq36 at kygur dot com @ 2024-05-12 10:19 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #41 from Brjd <brjd_epdjq36 at kygur dot com> --- (In reply to Sam James from comment #40) > That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29. IMHO keeping the build at RAM<=1GB would be a good benchmark. Keeping these million-line files might be wrong.I succeed at building it only with -j1. If j>1, the build simply errors. I read comments that j>1 builds might be bad to the drives too. If you know other possible ways to reduce RAM, please tell. ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2024-05-12 10:19 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-05 11:05 [Bug c/54179] New: please split insn-emit.c ! jason.vas.dias at gmail dot com 2012-08-05 11:11 ` [Bug c/54179] " jason.vas.dias at gmail dot com 2012-08-05 11:22 ` wbrana at gmail dot com 2012-08-05 11:36 ` jason.vas.dias at gmail dot com 2012-08-05 11:43 ` jason.vas.dias at gmail dot com 2012-08-05 12:01 ` wbrana at gmail dot com 2012-08-05 12:04 ` steven at gcc dot gnu.org 2012-08-05 12:21 ` jason.vas.dias at gmail dot com 2012-08-05 12:28 ` wbrana at gmail dot com 2012-08-05 12:34 ` steven at gcc dot gnu.org 2012-08-05 12:37 ` steven at gcc dot gnu.org 2012-08-05 13:16 ` jason.vas.dias at gmail dot com 2012-08-05 13:31 ` wbrana at gmail dot com 2012-08-05 13:43 ` jason.vas.dias at gmail dot com 2012-08-05 13:46 ` jason.vas.dias at gmail dot com 2012-08-05 13:51 ` jason.vas.dias at gmail dot com 2012-08-05 13:54 ` steven at gcc dot gnu.org 2012-08-05 13:55 ` steven at gcc dot gnu.org 2012-08-05 14:12 ` wbrana at gmail dot com 2012-08-05 14:13 ` schwab@linux-m68k.org 2012-08-05 18:10 ` jason.vas.dias at gmail dot com 2012-08-05 18:39 ` steven at gcc dot gnu.org 2012-08-05 19:49 ` jason.vas.dias at gmail dot com 2012-08-05 19:52 ` jason.vas.dias at gmail dot com 2012-08-05 20:10 ` jason.vas.dias at gmail dot com 2012-08-05 20:17 ` steven at gcc dot gnu.org 2012-08-05 20:58 ` jason.vas.dias at gmail dot com 2012-08-05 21:05 ` steven at gcc dot gnu.org 2012-08-06 8:43 ` rguenth at gcc dot gnu.org 2012-08-06 9:11 ` steven at gcc dot gnu.org 2012-08-06 10:49 ` steven at gcc dot gnu.org 2023-07-06 10:49 ` mmokrejs at gmail dot com 2023-07-07 11:29 ` sjames at gcc dot gnu.org 2023-07-07 11:39 ` [Bug bootstrap/54179] " tnfchris at gcc dot gnu.org 2023-07-07 12:47 ` mmokrejs at gmail dot com 2023-10-31 12:48 ` sjames at gcc dot gnu.org 2023-11-13 13:07 ` brjd_epdjq36 at kygur dot com 2023-11-13 15:03 ` xry111 at gcc dot gnu.org 2023-11-13 15:12 ` brjd_epdjq36 at kygur dot com 2024-05-11 12:08 ` brjd_epdjq36 at kygur dot com 2024-05-12 4:29 ` sjames at gcc dot gnu.org 2024-05-12 10:19 ` brjd_epdjq36 at kygur dot com
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).