[Bug tree-optimization/103188] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[Bug tree-optimization/103188] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 103188
           Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
                    Segmentation fault
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[635] % gcctk -O2 small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[636] %
[636] %
[636] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211111 (experimental) [master r12-5143-ga97fdde627e] (GCC)
[637] %
[637] % gcctk -O1 small.c; ./a.out
[638] %
[638] % gcctk -O2 small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[639] %
[639] % cat small.c
int a, b, c, d = 10, e = 1, f, g, h, i;
int main() {
  int j = -1;
k:
  h = c;
l:
  c = ~c;
  if (e)
  m:
    a = 0;
  if (j > 1)
    goto m;
  if (!e)
    goto l;
  if (c)
    goto p;
n:
  goto m;
o:
  if (f) {
    if (g)
      goto k;
    j = 0;
  p:
    if (d)
      goto o;
    goto n;
  }
  if (i)
    goto l;
  for (; a < 1; a++)
    while (a > d)
      b++;
  return 0;
}

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |12.0
     Ever confirmed|0                           |1
                 CC|                            |acoplan at gcc dot gnu.org
   Last reconfirmed|                            |2021-11-11

--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Confirmed with an x864 -> aarch64-linux-gnu cross. Looks like a stack overflow
in SCEV:

#0  0x0000000000d05c54 in ei_container (i=<error reading variable: Cannot
access memory at address 0x7ffffbffeff0>) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:381
#1  0x0000000000d05d05 in ei_end_p (i=...) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:418
#2  0x0000000000d05de9 in ei_cond (ei=..., p=0x7ffffbfff098) at
/home/alecop01/toolchain/src/gcc/gcc/basic-block.h:468
#3  0x0000000000d0aa4e in loop_preheader_edge (loop=0x7ffff64d5d40) at
/home/alecop01/toolchain/src/gcc/gcc/cfgloop.c:1763
#4  0x000000000158d479 in block_before_loop (loop=0x7ffff64d5d40) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.h:52
#5  0x0000000001591a72 in analyze_scalar_evolution (loop=0x7ffff64d5d40,
var=0x7ffff6344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2027
#6  0x000000000159064f in interpret_rhs_expr (loop=0x7ffff64d5d40,
at_stmt=0x7ffff64c8108, type=0x7ffff64dd5e8, rhs1=0x7ffff6344870,
code=PLUS_EXPR, rhs2=0x7ffff64e11b0) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1714
#7  0x000000000159174b in interpret_gimple_assign (loop=0x7ffff64d5d40,
stmt=0x7ffff64c8108) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1920
#8  0x00000000015918c0 in analyze_scalar_evolution_1 (loop=0x7ffff64d5d40,
var=0x7ffff6344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1969
#9  0x0000000001591ad2 in analyze_scalar_evolution (loop=0x7ffff64d5d40,
var=0x7ffff6344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2038
#10 0x000000000158fe73 in interpret_condition_phi (loop=0x7ffff64d5d40,
condition_phi=0x7ffff6386500) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1602
#11 0x0000000001591918 in analyze_scalar_evolution_1 (loop=0x7ffff64d5d40,
var=0x7ffff6344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1976
#12 0x0000000001591ad2 in analyze_scalar_evolution (loop=0x7ffff64d5d40,
var=0x7ffff6344870) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:2038
#13 0x000000000159064f in interpret_rhs_expr (loop=0x7ffff64d5d40,
at_stmt=0x7ffff64c8108, type=0x7ffff64dd5e8, rhs1=0x7ffff6344870,
code=PLUS_EXPR, rhs2=0x7ffff64e11b0) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1714
#14 0x000000000159174b in interpret_gimple_assign (loop=0x7ffff64d5d40,
stmt=0x7ffff64c8108) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1920
#15 0x00000000015918c0 in analyze_scalar_evolution_1 (loop=0x7ffff64d5d40,
var=0x7ffff6344558) at
/home/alecop01/toolchain/src/gcc/gcc/tree-scalar-evolution.c:1969
[...]

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at

#666394 0x00000000015f2170 in should_duplicate_loop_header_p (
    header=<basic_block 0x7ffff654fbc8 (14)>, loop=0x7ffff66aa9f0, 
    limit=0x7fffffffd97c, query=0x3fccb70)
    at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
83            && !entry_loop_condition_is_static (loop, query))

likely ranger is confused by the intermediate IL (from other loops header
copying), the IL is kept partly not in up-to-date SSA form (because running
update_ssa is costly so we run it once after doing all header copying in
a function).

In this case we applied loop header copying to loop 4 containing loop 5
which we are now processing.

Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
in a stmt are still old and _not_ replaced with their current definition.
There's only so much you can do with such IL, in particular invoking SCEV
isn't among that.

You can actually check whether a SSA name may be affected by checking
name_registered_for_update_p.  SCEV doesn't do that.

In the end that means that we'd have to do the ranger analysis before
actually applying the header copying.

Note that the current place of the

  /* Avoid loop header copying when optimizing for size unless we can
     determine that the loop condition is static in the first
     iteration.  */
  if (optimize_loop_for_size_p (loop)
      && !loop->force_vectorize
      && !entry_loop_condition_is_static (loop, query))
    {

is off in any case, since we iterate on blocks to copy, instead it should
be done exactly once per loop.  So we can do the "head", up until this
and the very first should_duplicate_loop_header_p first for each loop,
recording candidates in a vector and in a second loop process them all,
not doing the already done entry_loop_condition_is_static.

Let me cook up a patch to do that.

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 51767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51767&action=edit
patch I am testing

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |26163

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
This breaks some SPEC benchmark builds:
warning: 447.dealII(peak; CE) benchmark build failed!
warning: 454.calculix(peak; CE) benchmark build failed!
warning: 464.h264ref(peak; CE) benchmark build failed!


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
And reproduces with: gcc gcc/testsuite/gcc.dg/guality/pr89892.c -Os
-ftree-vectorize

[Bug tree-optimization/103188] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:8865133614f09caadf48c0b7d05f0331959b3bc1

commit r12-5155-g8865133614f09caadf48c0b7d05f0331959b3bc1
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Nov 11 14:05:49 2021 +0100

    tree-optimization/103188 - avoid running ranger on not-up-to-date SSA

    The following splits loop header copying into an analysis phase
    that uses ranger and a transform phase that can do without to avoid
    running ranger on IL that has SSA form not updated.

    2021-11-11  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/103188
            * tree-ssa-loop-ch.c (should_duplicate_loop_header_p):
            Remove query parameter, split out check for size
            optimization.
            (ch_base::m_ranger, cb_base::m_query): Remove.
            (ch_base::copy_headers): Split processing loop into
            analysis around which we allocate and use ranger and
            transform where we do not.
            (pass_ch::execute): Do not allocate/free ranger here.
            (pass_ch_vect::execute): Likewise.

            * gcc.dg/torture/pr103188.c: New testcase.

[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE on valid code at -O2    |[12 Regression] ICE on
                   |and -O3 on                  |valid code at -O2 and -O3
                   |x86_64-linux-gnu:           |on x86_64-linux-gnu:
                   |Segmentation fault          |Segmentation fault
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
           Priority|P3                          |P1
   Target Milestone|---                         |12.0

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault

[aldyh at redhat dot com]

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

Aldy Hernandez <aldyh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at redhat dot com,
                   |                            |amacleod at redhat dot com

--- Comment #9 from Aldy Hernandez <aldyh at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots at
> 
> #666394 0x00000000015f2170 in should_duplicate_loop_header_p (
>     header=<basic_block 0x7ffff654fbc8 (14)>, loop=0x7ffff66aa9f0, 
>     limit=0x7fffffffd97c, query=0x3fccb70)
>     at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83
> 83            && !entry_loop_condition_is_static (loop, query))
> 
> likely ranger is confused by the intermediate IL (from other loops header
> copying), the IL is kept partly not in up-to-date SSA form (because running
> update_ssa is costly so we run it once after doing all header copying in
> a function).

Ughh, yeah.  Ranger won't do well with in-flight SSA.  I think we can do ok
with minimally changing IL like what evrp does with the substitute and fold
engine, but we expect things quite sane.

When working on this patch I saw the call to gimple_duplicate_sese_region would
increase the number of BBs, which caused problems in the cache and Andrew
fixed.  I thought that was it for issues, obviously not.

> 
> In this case we applied loop header copying to loop 4 containing loop 5
> which we are now processing.
> 
> Not up-to-date SSA form means that while SSA defs are copied, the SSA uses
> in a stmt are still old and _not_ replaced with their current definition.
> There's only so much you can do with such IL, in particular invoking SCEV
> isn't among that.
> 
> You can actually check whether a SSA name may be affected by checking
> name_registered_for_update_p.  SCEV doesn't do that.

Hmmm, useful.

> 
> In the end that means that we'd have to do the ranger analysis before
> actually applying the header copying.
> 
> Note that the current place of the
> 
>   /* Avoid loop header copying when optimizing for size unless we can
>      determine that the loop condition is static in the first
>      iteration.  */
>   if (optimize_loop_for_size_p (loop)
>       && !loop->force_vectorize
>       && !entry_loop_condition_is_static (loop, query))
>     {
> 
> is off in any case, since we iterate on blocks to copy, instead it should
> be done exactly once per loop.  So we can do the "head", up until this
> and the very first should_duplicate_loop_header_p first for each loop,
> recording candidates in a vector and in a second loop process them all,
> not doing the already done entry_loop_condition_is_static.
> 
> Let me cook up a patch to do that.

Thanks for fixing this!