https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68671
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-12-03
CC| |jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This goes wrong during reassoc1. We have before that:
<bb 2>:
a.0_2 ={v} a;
c_3 = (signed char) a.0_2;
if (c_3 >= 0)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
# RANGE [0, 127] NONZERO 127
_4 = (int) c_3;
if (_4 == 0)
goto <bb 7>;
else
goto <bb 4>;
<bb 4>:
b ={v} 0;
# RANGE [-128, 127]
_6 = (int) c_3;
Reassoc1 performs:
Optimizing range tests c_3 +[0, 0] and +[0, ]
into c_3 == 0
and changes that to:
<bb 2>:
a.0_2 ={v} a;
c_3 = (signed char) a.0_2;
if (1 != 0)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
# RANGE [0, 127] NONZERO 127
_4 = (int) c_3;
_17 = c_3 == 0;
if (_17 != 0)
goto <bb 7>;
else
goto <bb 4>;
<bb 4>:
b ={v} 0;
# RANGE [-128, 127]
_6 = (int) c_3;
That is almost fine, except it turns a previously only conditional _4 = (int)
c3; to be now unconditionally executed (also not wrong), but the bug is that it
doesn't have its value range reset when performing this optimization.
Later on PRE finds out that _6 has the same value as _4 and uses _4 everywhere,
but as _4 has the incorrect value range, we miscompile the testcase to always
abort.
