[Bug c/54179] New: please split insn-emit.c !

[Bug c/54179] New: please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[wbrana at gmail dot com]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[wbrana at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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?

[Bug c/54179] please split insn-emit.c !

[wbrana at gmail dot com]

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.

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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?

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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
?

[Bug c/54179] please split insn-emit.c !

[wbrana at gmail dot com]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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 \

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[wbrana at gmail dot com]

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.

[Bug c/54179] please split insn-emit.c !

[schwab@linux-m68k.org]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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.

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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 :-) !

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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...

[Bug c/54179] please split insn-emit.c !

[jason.vas.dias at gmail dot com]

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 ?

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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).

[Bug c/54179] please split insn-emit.c !

[rguenth at gcc dot gnu.org]

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 ?

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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.

[Bug c/54179] please split insn-emit.c !

[mmokrejs at gmail dot com]

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'

[Bug c/54179] please split insn-emit.c !

[sjames at gcc dot gnu.org]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[tnfchris at gcc dot gnu.org]

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 :)

[Bug bootstrap/54179] please split insn-emit.c !

[mmokrejs at gmail dot com]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[sjames at gcc dot gnu.org]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[brjd_epdjq36 at kygur dot com]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[xry111 at gcc dot gnu.org]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[brjd_epdjq36 at kygur dot com]

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:)

[Bug bootstrap/54179] please split insn-emit.c !

[brjd_epdjq36 at kygur dot com]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[sjames at gcc dot gnu.org]

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.

[Bug bootstrap/54179] please split insn-emit.c !

[brjd_epdjq36 at kygur dot com]

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.