[Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-07-19
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
This test case has unreachable code in it. 
This issue comes down to

  func_14_s_5.0_1 = func_14_s_5;
  _2 = func_14_s_5.0_1 < 0;
  c_1.2_4 = c_1;
  _5 = func_14_s_5.0_1 != c_1.2_4;
  _6 = _2 | _5;
  _7 = (int) _6;
  us_3.3_8 = us_3;
  _9 = _7 | us_3.3_8;
  us_3 = _9;
  us_3.6_11 = (unsigned int) _9;
  if (us_3.6_11 == 0)
    goto <bb 4>; [INV]
  else
    goto <bb 9>; [INV]

We determine that in order for us_3.6_11 to be == 0 and take the branch to bb4,
that _9, _7, _2 and _5 must all also be 0.   This means that
_5 = func_14_s_5.0_1 != c_1.2_4;
must be false, which then means that
  func_14_s_5.0_1 == c_1.2_4

_2 being false also means func_14_s_5.0_1 >= 0 or  [0, +INF]

Next:
  <bb 4> :
  _16 = c_1.2_4 >= _9;
  _17 = (unsigned int) _16;
  if (_17 != 0)
    goto <bb 9>; [INV]
  else
    goto <bb 5>; [INV]

to take the branch to bb5, c_1.2_4 must be < _9, (_9 is known to be [0,0]..
meaning its range would be [-INF, -1].

we arent fully exploiting equivalences yet, so we dont fold this branch, even
though we potentially could.  With  func_14_s_5.0_1 == c_1.2_4, that means
c_1.2_4 will enter this branch with the range [0, +INF] which means it can
never be < _9 and we will always branch to BB 9.   We currently miss that fold,
so don't realize yet that bb_5 in unreachable.

but this leads us to the next branch, which is causing the problem:
  <bb 6> :
  if (func_14_s_5.0_1 <= c_1.2_4)
    goto <bb 8>; [INV]
  else
    goto <bb 7>; [INV]

Ranger first tries to fold with relations, so it determines that this is always
TRUE since func_14_s_5.0_1 == c_1.2_4.  The simplification code still has
legacy support in it, and confirms that whatever we come up with the with new
range API matches the old code.  The old code says   
 func_14_s_5.0_1 == [0, +INF],  and c_1.2_4 == [-INF, -1], so this branch is
never taken.. result is FALSE.
Now an assert it tripped saying the 2 approaches do not agree on which edge
would be taken. The code is unreachable.. so it doesnt really matter.

To fix this, I am tweaking the simplification code for now to simply use the
value the new API returns, if it returns one.
Otherwise, it then checks the old API and the only time it is allowed to find a
taken edge is if the NEW API says the fold is undefined. 

Eventually we can remove that too, but for now, I leave it as a sanity check to
ensure we dont find something important, and it is harmless for the OLD API
code to remove unreachable code.


This function eventually folds to
  <bb 2> [local count: 10631108]:

  <bb 3> [local count: 1073741824]:
  goto <bb 3>;