[Bug c/106995] New: gcc-trunk crash at -O2

[Bug c/106995] New: gcc-trunk crash at -O2

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 106995
           Summary: gcc-trunk crash at -O2
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
  Target Milestone: ---

% gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-1e4c7e870e2a3a059568565196a8f3b8c9de1fa4/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-1e4c7e870e2a3a059568565196a8f3b8c9de1fa4
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220915 (experimental) (GCC)
%
% gcc-tk -w -O1 a.c
during RTL pass: expand
simple.c: In function ‘i’:
simple.c:4:1: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.cc:2729
    4 | i() {
      | ^
0x2033eee internal_error(char const*, ...)
        ???:0
0x998592 fancy_abort(char const*, int, char const*)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
%
% cat a.c
a, b, c, d;
static unsigned long *e = &b, *f = &b;
g(h) { return a >= 2 ? 0 : h >> a; }
i() {
  for (; c;) {
    if (*f ^ 11)
      for (;;)
        ;
    d = g(0 >= 0);
    *e = d;
  }
}
main() {}
%

Compiler explorer: https://godbolt.org/z/4a5WYn4fM

[Bug tree-optimization/106995] gcc-trunk crash at -O2

[shaohua.li at inf dot ethz.ch]

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

--- Comment #1 from Li Shaohua <shaohua.li at inf dot ethz.ch> ---
Sorry, it should be `gcc-tk -w -O2 a.c`

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-21
                 CC|                            |aldyh at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
            Summary|gcc-trunk crash at -O2      |[13 Regression] ICE in
                   |                            |expand_LOOP_VECTORIZED, at
                   |                            |internal-fn.cc:2720  with
                   |                            |-O2 since
                   |                            |r13-1598-g0a7e721a6499a42f

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Thanks for the report, please do not over-reduce test-cases so that it's full
of warnings.

Fixed test-case:

$ cat pr106995.c
int a, b, c, d;
static unsigned long *e = &b, *f = &b;

int
g(int h) { return a >= 2 ? 0 : h >> a; }

void
i() {
  for (; c;) {
    if (*f ^ 11)
      for (;;)
        ;
    d = g(0 >= 0);
    *e = d;
  }
}

int main() {}

Started with r13-1598-g0a7e721a6499a42f.

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that during if-conversion VN we figure the loop exit is
unreachable and thus elide the loop but not the if (.LOOP_VECTORIZED) call ...

Region does not contain all edges into the entry block, skipping its PHIs.
Processing block 0: BB8
Cannot trust state of predecessor edge 16 -> 8, marking executable
Value numbering stmt = _9 = (long unsigned int) iftmp.0_11;
Setting value number of _9 to _9 (changed)
Making available beyond BB8 _9 for value _9
Value numbering stmt = _6 = a.1_8 <= 1;
Setting value number of _6 to _6 (changed)
Making available beyond BB8 _6 for value _6
Value numbering stmt = iftmp.0_12 = _6 ? iftmp.0_11 : 0;
Setting value number of iftmp.0_12 to iftmp.0_12 (changed)
Making available beyond BB8 iftmp.0_12 for value iftmp.0_12
Value numbering stmt = prephitmp_10 = _6 ? _9 : 0;
Setting value number of prephitmp_10 to prephitmp_10 (changed)
Making available beyond BB8 prephitmp_10 for value prephitmp_10
Value numbering stmt = if (prephitmp_10 != 11)
marking destination block 16 reachable

probably a latent issue for a while.

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will try to find a solution for this.

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 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:063ba138eaa15ceecf23a24906e0e19be98d509d

commit r13-4388-g063ba138eaa15ceecf23a24906e0e19be98d509d
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Nov 29 10:41:36 2022 +0100

    tree-optimization/106995 - if-conversion and vanishing loops

    When we version loops for vectorization during if-conversion it
    can happen that either loop vanishes because we run some VN and
    CFG cleanup.  If the to-be vectorized part vanishes we already
    redirect the versioning condition to the original loop.  The following
    does the same in case the original loop vanishes as happened
    for the testcase in the bug in the past (but no longer).

            PR tree-optimization/106995
            * tree-if-conv.cc (pass_if_conversion::execute): Also redirect the
            versioning condition to the original loop if this very loop
            vanished during CFG cleanup.

[Bug tree-optimization/106995] [13 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.cc:2720 with -O2 since r13-1598-g0a7e721a6499a42f

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue became latent but this should fix it.