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>;
