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

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.

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

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

(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

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

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?

2 GB RAM isn't enough.
It isn't good idea to use x86_64 with 2 GB RAM.

(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?

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

    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 ?

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.

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

$ 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

Created attachment 27939 [details]
pre-processed "C" from previous comment command

$ xz --uncompress < insn-emit.i.xz > insn-emit.i 
# pre-processed "C" from previous comment command

> $ /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 \

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

(In reply to comment #17)
> Sorry, but this is just rubbish.
You didn't confute my statements.

GCC can comfortably be built with just 1GB of memory.

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

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

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.

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

$ 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

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

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 ?

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

(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 ?

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

Created attachment 27950 [details]
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.

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'

I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about this, apologies if I'm misremembering.

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

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.

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.

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.

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

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

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.

That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29.

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