This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]