[Bug c++/79416] Internal compiler error for recursive template expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- With trunk I get: phase opt and generate : 82.04 (100%) 25.20 (100%) 107.23 (100%) 15103M (100%) callgraph ipa passes : 78.81 ( 96%) 24.72 ( 98%) 103.53 ( 96%) 15021M ( 99%) integration: 32.50 ( 40%) 8.29 ( 33%) 40.44 ( 38%) 10311M ( 68%) tree Early VRP : 4.28 ( 5%) 0.04 ( 0%) 4.13 ( 4%) 1154k ( 0%) tree operand scan : 13.42 ( 16%) 4.64 ( 18%) 18.23 ( 17%) 1409M ( 9%) remove unused locals : 6.16 ( 8%) 0.07 ( 0%) 6.12 ( 6%) 0 ( 0%) 13% of overall runtime is ggc_internal_alloc. I wonder why early VRP become expensive. Also remove unused locals could be quite likely tamed down - we run it many times and perhaps we can keep tract of changes.
[Bug c++/79416] Internal compiler error for recursive template expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog, ||memory-hog Severity|normal |minor Target Milestone|5.5 |---
[Bug c++/79416] Internal compiler error for recursive template expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79416 Jason Merrill changed: What|Removed |Added Priority|P2 |P3 CC||jason at gcc dot gnu.org Summary|[5/6/7 Regression] Internal |Internal compiler error for |compiler error for |recursive template |recursive template |expansion |expansion | --- Comment #3 from Jason Merrill --- This is about running out of stack, instantiating a ridiculous number of functions that call each other. The error Martin sees in comment 1 is because the old default instantiation limit of 500 was lower than the 800 instantiations the testcase wants to make of the 'nops' functions; since the limit was raised to 900, we succeed in instantiating them, but then crash running out of stack during ggc_collect. Comment 2 demonstrates that we can get the same crash on older GCC by lowering the number of instantiations the testcase requires, so this really isn't a regression. A simple fix for the crash would be to raise the stack limit; doubling the amount requested in the call to stack_limit_increase from toplev::main (from 64MB to 128MB) allows the testcase to proceed. A difficult fix for the crash would be to reduce the stack consumption of the GGC machinery.
