http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48880
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.05.05 08:49:13
CC| |hubicka at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-05
08:49:13 UTC ---
The testcase is quite questionable, and the reason it "fails" with gcc 4.6 is
partial inlining. Related to PR46639, again being able to run VRP through the
body of the partially inlined fn before handling the p.part.0 VRP would fix
this.
In *.fnsplit p is:
p (unsigned int n)
{
int D.2699;
<bb 2>:
if (n_2(D) == 0)
goto <bb 5>;
else
goto <bb 3>;
<bb 3>:
if (n_2(D) > 3)
goto <bb 5>;
else
goto <bb 4>;
<bb 4>:
D.2699_9 = p.part.0 (n_2(D));
<bb 5>:
# D.2699_1 = PHI <0(2), -22(3), D.2699_9(4)>
return D.2699_1;
}
so if VRP would figure out that p.part.0's first argument has range [1, 3], it
could optimize away the test in p.part.0.
