https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
OK, there are a couple of things at play in this PR.
The original problem isn't actually unreachable code. well, sort of.
The pass determines something is unreachable and changes the condition, which
means it will be unreachable when its done.. but the dom walk will continue.
The issue is that this triggers a case where EVRP gets a singleton that we
miss, and thats what triggers the stmt rewrite.,
_2 = add_type_duplicate_type.2_1->base.code;
_3 = (int) _2;
Theres a chaining of conditions with _3 and _2
<bb 3> :
if (_2 == 0)
goto <bb 7>; [INV]
<bb 7> :
if (_3 != 0)
goto <bb 8>; [66.00%]
if (_3 != 1)
goto <bb 9>; [0.04%]
else
goto <bb 10>; [99.96%]
<bb 10> :
if (add_type_duplicate_type.2_1 != 0B)
goto <bb 4>; [INV]
<bb 4> :
if (_3 != 0)
goto <bb 5>; [66.00%]
And at some point (and I know where and why, the cast chain being in a
different block than the condition... its on my list) ranger loses track that
_3 is actually [0,0], and instead thinks its still [0,1]
so EVRP finds the singlton [0,0] and turns
vrp visiting stmt if (_3 != 0)
Folding statement: if (_3 != 0)
into if (0 != 0)
Which of course makes some code look unreachable (and it will be when the CFG
is updated.)
Meanwhile we plug along, and since the ranger is dynamic, that condition now
factors into any calculations, and when we get to a later statement,
evrp visiting stmt if (_3 != 1)
using this new found information, ranger says, aha, I can refine [0,1] for _3,
is actually [1,1] on one edge, whereas evrp simply reports the [0,0] it already
had.
bottom line, its triggered by ranger missing something...
I wasn't expecting this to trigger due to shortcomings... I was expecting it to
be just bugs.
given that, I think I will change this to again, flag the difference like I do
with ranges, and use the value produced by whichever pass is going first.
That way we wont be stopped by this sort of issue when its really just a
shortcoming.
