[Bug c/103093] New: ice in get_imports, at gimple-range-gori.cc:221

[Bug c/103093] New: ice in get_imports, at gimple-range-gori.cc:221

[dcb314 at hotmail dot com]

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

            Bug ID: 103093
           Summary: ice in get_imports, at gimple-range-gori.cc:221
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C source code:

int i_0, c_4, uc_7, func_2_c_11;

short *func_2_ptr_10;

void func_2() {
  uc_7 = 7;
  for (; uc_7 <= 60; uc_7 += 1) {
    c_4 = 5;
    for (; c_4 <= 76; c_4 += 1) {
      func_2_ptr_10 = &i_0;
      if ((i_0 |= 5) > 0 ?: (60 && uc_7) | *func_2_ptr_10)
        if (func_2_c_11)
          for (;;)
            ;
    }
  }
}

compiled with recent trunk gcc and compiler flag -O2, does this:

$ /home/dcb/gcc/results/bin/gcc -c -w -O2 bug769.c
during GIMPLE pass: vrp
bug769.c: In function ‘func_2’:
bug769.c:5:6: internal compiler error: in get_imports, at
gimple-range-gori.cc:221
    5 | void func_2() {
      |      ^~~~~~
0x1ae51cf range_def_chain::get_imports(tree_node*)
        ../../trunk.git/gcc/gimple-range-gori.cc:220

The bug first seems to occur sometime between git hash a11c53985a7080f9
and c79399c7e128a3ea, range of 44 commits.

[Bug tree-optimization/103093] [12 Regression] ice in get_imports, at gimple-range-gori.cc:221

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
     Ever confirmed|0                           |1
   Target Milestone|---                         |12.0
            Summary|ice in get_imports, at      |[12 Regression] ice in
                   |gimple-range-gori.cc:221    |get_imports, at
                   |                            |gimple-range-gori.cc:221
             Status|UNCONFIRMED                 |NEW
                 CC|                            |aldyh at gcc dot gnu.org
           Keywords|                            |ice-on-valid-code
          Component|c                           |tree-optimization
   Last reconfirmed|                            |2021-11-05

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
            Summary|[12 Regression] ice in      |[12 Regression] ICE in
                   |get_imports, at             |get_imports, at
                   |gimple-range-gori.cc:221    |gimple-range-gori.cc:221
                   |                            |since
                   |                            |r12-4788-gcb596fd43667f92c

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
With --param=vrp2-mode=ranger, it started with r12-4788-gcb596fd43667f92c.

[Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
This is a case of a series of statements being simplified, and the IL rewritten
to be quite different:
it starts with

  _3 = uc_7.9_28 != 0;
  _4 = (int) _3;
  _25 = BIT_FIELD_REF <_2, 16, 0>;
  _6 = (int) _25;
  _7 = _4 | _6;

Since range-ops doesn't understand the BIT_FIELD_REF operator, _25 is
considered an import to the defchain for _7.

Folding statement: _7 = _4 | _6;
and ends up changing this to:
  _3 = uc_7.9_28 != 0;
  _4 = (int) _3;
  _25 = (short int) _2;
  _6 = (int) _25;
  _22 = _25 | 1;
  _7 = (int) _22


and then later we are looking to calculate a range from an outgoing edge in
this block, and when GORI steps back to this statement, it steps back from _7
into _22, sees it does not have a dependency chain, so calculates one for it.
It finds that _2 is the import, which means the imports no longer match up for
_7, so it triggers an assert that something is amok with the dependency chain
imports.

Internally ranger doesn't use these imports for anything significant, so the
fact that they are out of date is not particularly important in the presence of
IL that is being updating.  

GORI will also continue to calculate based on what is in the stmt, all that may
change is if the dependencies are different enough, it will be unable to
calculate thru the chain properly since it wont be able to find a name in the
def chain that it is expecting, and will simply return false.  It won't affect
any already computed values, and will never result in a  wrong-code situation.

Updating existing def chains would be problematic as uses further down the def
chain would not be updated, so any of them could later trigger an inconsistency
assert. 

As such, I will simply remove the assert. It was primarily of use when we were
first introducing the import concept to make sure that there was consistency
when they were being built. In the presence of changing IL, the assert no
longer has much meaning.

[Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:1f6dd5de33912c261a5003150212c290165ac1b6

commit r12-4948-g1f6dd5de33912c261a5003150212c290165ac1b6
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Fri Nov 5 11:25:09 2021 -0400

    Remove def chain import assert from GORI.

    When the IL has changed, any new ssa-names import calculations may not jive
    with existing ssa-names, so just remove the assert.

            gcc/
            PR tree-optimization/103093
            * gimple-range-gori.cc (range_def_chain::get_imports): Remove
assert.

            gcc/testsuite/
            * gcc.dg/pr103093.c: New.

[Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
Fixed.

[Bug tree-optimization/103093] [12 Regression] ICE in get_imports, at gimple-range-gori.cc:221 since r12-4788-gcb596fd43667f92c

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vsevolod.livinskij at frtk dot ru

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
*** Bug 103119 has been marked as a duplicate of this bug. ***