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.