This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 21 Jan 2015 10:30:11 +0000
- Subject: [Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
- Auto-submitted: auto-generated
- References: <bug-64511-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c0 issue is different (with the reorder_operands call commented out),
there var-tracking creates a huge (.5GB in text *.vartracking dump)
NOTE_INSN_CALL_ARG_LOCATION note and another huge (again about .5GB)
NOTE_INSN_VAR_LOCATION note. Don't understand how it got created, we have the
various depths limit in var-tracking expansion (expand_depth struct).
With --param max-vartrack-expr-depth=11 the testcase still compiles and even
the vartrack dump is 10 times smaller than with depth 12, on the other side
depth of 12 was needed for various real-world examples.
So perhaps we don't need to count just complexity/depth but should count also
number of rtxes involved and just give up if it goes over yet another parameter
(say 1000 or 10000 rtxes by default).
That said, I'd like to fix #c8 independently.