https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #8 from Jeffrey A. Law ---
Author: law
Date: Thu Oct 6 16:23:22 2016
New Revision: 240836
URL: https://gcc.gnu.org/viewcvs?rev=240836=gcc=rev
Log:
PR tree-optimization/71661
* tree-cfgcleanup.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #7 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #5)
> We can likely invalidate the cached information, but ISTM that there's a
> reasonable chance we're going to be playing whack-a-mole with this stuff.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #6 from Jeffrey A. Law ---
As noted in my last comment, removal of a forwarder block may turn an
irreducible loop into a natural loop. The loop header for any such exposed
natural loop will not be recognized as a loop header by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #5 from Jeffrey A. Law ---
So digging a bit deeper. When we leave threading we've exposed a new natural
loop. However, there is still an irreducible loop in the CFG. The CFG and the
cached loop information are conservatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
--- Comment #3 from Jakub Jelinek ---
This to me looks like some transformation of a loop that doesn't properly
adjust the number of iterations. During vrp1 loop2 is:
loop_2 (header = 11, latch = 13, niter = c_23 + 1 <= 3 ? 2 - c_23 : 0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71661
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
