[Bug c/64511] New: ICE at -O3 with -g enabled on x86_64-linux-gnu

[Bug c/64511] New: ICE at -O3 with -g enabled on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

            Bug ID: 64511
           Summary: ICE at -O3 with -g enabled on x86_64-linux-gnu
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The following code causes an ICE (after a very very long pause) when compiled
with the current gcc trunk at -O3 with -g enabled on x86_64-linux-gnu in 64-bit
mode (but not in 32-bit mode). 

It is a regression from 4.9.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150106 (experimental) [trunk revision 219217] (GCC) 

$ 
$ gcc-trunk -O3 -c small.c
$ gcc-4.9 -O3 -g -c small.c
$ 
$ time gcc-trunk -O3 -g -c small.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40c1de execute
    ../../gcc-trunk/gcc/gcc.c:2912
0x40c4e9 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:4845
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
0x40d4e7 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5499
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
0x40d4e7 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5499
0x40c873 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5614
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
0x40d4e7 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5499
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
0x40d4e7 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5499
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
0x40d4e7 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5499
0x40eaf7 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6128
0x40eaf7 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6042
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Command exited with non-zero status 4
50.56user 1.04system 2:06.99elapsed 40%CPU (0avgtext+0avgdata
5923360maxresident)k
56inputs+0outputs (4major+371046minor)pagefaults 0swaps
$ 


----------------------------------


char a;
unsigned short b;
int c;
unsigned long d;

void fn1 ()
{
  for (;;)
    ;
}

void fn2 (unsigned char p1)
{
  unsigned char *e = &p1;
  c = 27;
  for (; c < 37; c++)
    b *= (a %= ((*e %= *e) ^ 0));
  p1 /= d = a;
  fn1 (p1);
}

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

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-06
                 CC|                            |rguenther at suse dot de
   Target Milestone|---                         |5.0
            Summary|ICE at -O3 with -g enabled  |[5 Regression] ICE at -O3
                   |on x86_64-linux-gnu         |with -g enabled on
                   |                            |x86_64-linux-gnu
     Ever confirmed|0                           |1

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
It was caused by r216728.

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

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |debug

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
The explosion seems to be in var tracking.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |compile-time-hog,
                   |                            |memory-hog
             Status|ASSIGNED                    |NEW
           Assignee|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, nothing I can do about and I can't spot real differences during RTL
expansion.  TER gobbles up the whole function though and maybe debug
expression expansion is slightly different (also due to operand
canonicalization).

I note that we don't fold x % x (to preserve the x == 0 exception), a missed
optimization opportunity is to do

  if (x == 0)
   __builtin_trap ();

at the very first point we encounter that (possibly during VRP if VRP
detects that it can simplify further expressions with x != 0 knowledge).

Note that this bug may be an effective dup of another one.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
x % x for x == 0 is undefined behavior, so perhaps with the exception of
sanitization we can just assume it is not 0 and thus fold x % x to 0.
Or does e.g. Ada/Java require something different?

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, this problem went away with r219646.  Shall we declare it as fixed or at
least turn into non-regression?

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

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #8 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #7)
> Note, this problem went away with r219646.  Shall we declare it as fixed or
> at least turn into non-regression?

Jakub, the original unreduced test still fails with r219909.  Below is another
reduced test that causes the same ICE. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150120 (experimental) [trunk revision 219909] (GCC) 

$ 
$ gcc-trunk -O3 -g -c small.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40c27f execute
    ../../gcc-trunk/gcc/gcc.c:2913
0x40c589 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:4846
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40c913 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5615
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


------------------------------


int a, c;
int *volatile b;

void
fn1 (int p)
{
  int d;
  int *e = &a;
  d = ((p == 0) & *e) != 0;
  b = e;
  for (; c;)
    ;
}

void
fn2 ()
{
  fn1 (1);
}

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

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 20 Jan 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Note, this problem went away with r219646.  Shall we declare it as fixed or at
> least turn into non-regression?

I'd say the bug has gone latent again.  At some point we may decide to
drop the regression marker but for now I'd like somebody to investigate
and fix the issue.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c8 case can be easily fixed:
--- gcc/simplify-rtx.c.jj    2015-01-19 09:31:25.000000000 +0100
+++ gcc/simplify-rtx.c    2015-01-21 10:59:03.808280655 +0100
@@ -4589,7 +4589,8 @@ simplify_relational_operation_1 (enum rt
   if ((code == EQ || code == NE)
       && op0code == AND
       && rtx_equal_p (XEXP (op0, 0), op1)
-      && !side_effects_p (op1))
+      && !side_effects_p (op1)
+      && op1 != CONST0_RTX (cmp_mode))
     {
       rtx not_y = simplify_gen_unary (NOT, cmp_mode, XEXP (op0, 1), cmp_mode);
       rtx lhs = simplify_gen_binary (AND, cmp_mode, not_y, XEXP (op0, 0));
@@ -4602,7 +4603,8 @@ simplify_relational_operation_1 (enum rt
   if ((code == EQ || code == NE)
       && op0code == AND
       && rtx_equal_p (XEXP (op0, 1), op1)
-      && !side_effects_p (op1))
+      && !side_effects_p (op1)
+      && op1 != CONST0_RTX (cmp_mode))
     {
       rtx not_x = simplify_gen_unary (NOT, cmp_mode, XEXP (op0, 0), cmp_mode);
       rtx lhs = simplify_gen_binary (AND, cmp_mode, not_x, XEXP (op0, 1));

The thing is that the MEM has side_effects_p, thus we don't optimize (and (mem)
(const_int 0)) into (const_int 0), and this optimization turns the
(ne (and (mem) (const_int 0)) (const_int 0))
into
(ne (and (not (mem)) (const_int 0)) (const_int 0))
which is turned into:
(ne (and (mem) (const_int 0)) (const_int 0))
and so forth.  Whether this is a problem with the original testcase will have
to verify.

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

[jakub at gcc dot gnu.org]

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.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Jan 21 21:59:34 2015
New Revision: 219974

URL: https://gcc.gnu.org/viewcvs?rev=219974&root=gcc&view=rev
Log:
    PR debug/64511
    * simplify-rtx.c (simplify_relational_operation_1): Don't try to
    optimize (eq/ne (and (side_effects) (const_int 0)) (const_int 0))
    into (eq/ne (and (not (side_effects)) (const_int 0)) (const_int 0)).

    * gcc.dg/pr64511.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr64511.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/simplify-rtx.c
    trunk/gcc/testsuite/ChangeLog

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

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #13 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #11)
> The #c0 issue is different (with the reorder_operands call commented out),
...
> That said, I'd like to fix #c8 independently.

Jakub, indeed, #c8 was reduced from another test. I thought the two were the
same as they have the same exact stack trace. 

FYI, below is a reduced test from the same original test as for #c0. It fails
with r219963. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150121 (experimental) [trunk revision 219963] (GCC) 

$ 
$ gcc-trunk -O3 -g -c small2.c
$ 
$ time gcc-trunk -O3 -g -c small2.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40c27f execute
    ../../gcc-trunk/gcc/gcc.c:2913
0x40c589 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:4846
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40c913 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5615
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
    ../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
    ../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
    ../../gcc-trunk/gcc/gcc.c:6043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Command exited with non-zero status 4
8.05user 0.59system 0:12.84elapsed 67%CPU (0avgtext+0avgdata
3121136maxresident)k
0inputs+0outputs (0major+195936minor)pagefaults 0swaps
$ 


------------------------------------


extern void fn1 (int p1, int p2);

short d;

void fn2 (int p1, unsigned char p2)
{
  unsigned char k, *l = &p2;
  short m;
  for (m = 27; m < 37; m++)
    d *= *l %= *l;
  fn1 (p1 %= p2, p1 = k);
}

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note the stack traces involving do_spec_1 are generally bogus (should be
fixed), those stack traces are from the gcc driver rather than cc1/cc1plus
etc., and are printed because cc1/cc1plus segfaulted.

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

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #15 from Zhendong Su <su at cs dot ucdavis.edu> ---
(In reply to Jakub Jelinek from comment #14)
> Note the stack traces involving do_spec_1 are generally bogus (should be
> fixed), those stack traces are from the gcc driver rather than cc1/cc1plus
> etc., and are printed because cc1/cc1plus segfaulted.

Oh, I see; thanks for the info.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34531&action=edit
gcc5-pr64511.patch

The #c13 testcase can be fixed by the attached patch.  Not including the
testcase, as it takes 5 seconds to compile, which might be too much for the
testsuite.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Sun Feb  1 17:32:18 2015
New Revision: 220322

URL: https://gcc.gnu.org/viewcvs?rev=220322&root=gcc&view=rev
Log:
    Backported from mainline
    2015-01-23  Jakub Jelinek  <jakub@redhat.com>

    PR debug/64511
    * dwarf2out.c (struct dw_loc_descr_node): Add chain_next
    GTY markup.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/dwarf2out.h

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
-O3 -g testcase from PR64817 showing probably the same issue as #c0 with
reorder_operands reverted:

int a, b, d;

void
foo (void)
{
  for (b = 0; b < 9; b++)
    {
      int e;
      for (d = 0; d < 5; d++)
{
  a &= 231;
  a ^= 14;
}
      a ^= 1;
      e = (a < 0) + a;
    }
}

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

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

--- Comment #21 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I went back to r219641, just before the problem disappeared again, installed
the r220031 patch to fix the dwarf2out crash, and compilation completed
sucessfully in 36s.  Installing the patch for bug 64817 brought it down to 30s,
which is still arguably excessive, but...  we're not really doing anything
wrong here.  The huge debug loc exprs you see are the result of the compiler
looking for, and finding, an alternate representations for a variable, when a
register used in its previous location is modified.  What we have before
var-track is a sequence of groups of insns that each sets ebx to an expression
involving its prior value, and then binds a variable to it.  The chain of exprs
goes all the way back to an entry value (not in ebx), so the compiler
successfully builds more and more complex locations for the variable every time
ebx is modified, emitting a location for the variable, just to have the next
insn bind the variable to ebx.

One thing we could do to alleviate this specific scenario is to try to optimize
out the emission of a location when it's about to be modified again.  This
would address this particular issue, but it would be no help if the long chain
of exprs were to set different user variables, rather than the same.  Assuming
the program still optimizes to the same non-debug insns, as it should, we'd
have to recompute the location for each remaining user variable because it is
not rebound, and we'd end up with the same complex rtl referring all the way
back to entry-point values.

Lowering the max-vartrack-expr-depth by 1, down to 11, cuts the compile time
down to tenths of a second, so the complexity limiters we have in place are
doing their job, it's just that this rtl turns out to be particularly expensive
to handle.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Considering this fixed with latest PR64817 fixes.