Created attachment 1477650 [details] test.tar.gz Standard gcc 4, on rhel6 and rhel7 do not have the issue. The example is from auto generated C code, that might generate thousands of setjmp calls. It will either get OOM killed, or take a really long time to compile. Under gdb, and with gcc 7, the backtrace when it starts to consume a lot of memory looks like: (gdb) bt #0 0x000000000087423a in bmp_iter_set () #1 0x0000000001037a64 in coalesce_ssa_name() () #2 0x000000000100543c in rewrite_out_of_ssa(ssaexpand*) () #3 0x0000000000db5ea3 in (anonymous namespace)::pass_expand::execute(function*) () #4 0x0000000000f6610b in execute_one_pass(opt_pass*) () #5 0x0000000000f6834c in execute_pass_list(function*, opt_pass*) () #6 0x00000000012a3292 in cgraph_node::expand() () #7 0x00000000012a2f8a in output_in_order(bool) () #8 0x00000000012a2a64 in symbol_table::compile() () #9 0x0000000000de4c4f in symbol_table::finalize_compilation_unit() () #10 0x00000000012e992f in compile_file() () #11 0x0000000000d3b341 in toplev::main(int, char**) () #12 0x0000000000d3cc1b in main () Under -O0 I tested disabling all -fdump-pass enabled, and it will either cause an ICE or reproduce the problem (did not wait for OOM killed for all -fdisable-... after 5 seconds). To test: $ tar xf test.tar $ cd test $ ./gcc_tc_gens.sh can edit the script to remove -m32 or other compiler options.
Regarding the gcc bugzilla, is there any news on comments #13 and #14 ?
No, if there were any news, the PR would have been updated. Reproduced with GCC 8. Not going to be fixed for DTS 8.0, unfortunately.
The dramatically increased memory consumption and compile time is directly related to the need to fix inaccuracies in the control graph. Essentially in old versions of GCC the CFG was inaccurate and dramatically smaller. Those inaccuracies could ultimately result in incorrect code. Fixing the inaccuracies dramatically increased the size of the CFG and consequently the number and size of PHI nodes, coalescing maps, etc etc. Most of Richi's work from Oct in this space is not back portable. The one piece that was backportable is just a compile-time improvement when the optimizer is enabled. It does not reduce memory consumption in any meaningful way. That work will appear in DTS 8.1, but will not resolve the memory consumption concerns.
I think there's a chance this is fixed (or at least very much improved) in DTS 9. But we should check, to be sure.
I was disappointed to find out that there was no improvement: # ./gcc_tc_gens.sh GCC: 4.8.5 OPTIMIZATION: -O0 real 0m0.263s user 0m0.234s sys 0m0.029s OPTIMIZATION: -O3 real 0m0.374s user 0m0.346s sys 0m0.028s # ./gcc_tc_gens.sh GCC: 8 OPTIMIZATION: -O0 real 0m26.517s user 0m24.708s sys 0m1.799s OPTIMIZATION: -O3 real 0m29.075s user 0m27.209s sys 0m1.854s # ./gcc_tc_gens.sh GCC: 9 OPTIMIZATION: -O0 real 0m27.035s user 0m25.374s sys 0m1.661s OPTIMIZATION: -O3 real 0m31.325s user 0m29.427s sys 0m1.892s So DTS 9.1 for now.
*** Bug 1731220 has been marked as a duplicate of this bug. ***
The dramatic slowdown started with https://gcc.gnu.org/r198096, same issue as in Bug 1731220.
$ time ./cc1.198095 -quiet -O3 ~/gcc_gened_test_1000_pure_c.i real 0m2.685s user 0m2.650s sys 0m0.024s $ time ./cc1.198096 -quiet -O3 ~/gcc_gened_test_1000_pure_c.i Killed real 16m39.734s user 10m28.248s sys 3m14.404s