http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47899
--- Comment #4 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2011-03-01 22:13:15 UTC --- Created attachment 23508 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23508 proposed fix When the non-exit path is removed during the complete peeling of the loop, we may need to move some basic blocks up the loop hierarchy (this happens when this removal destroys the path from the bb to the latch of the considered superloop). We achieve this by iteratively moving blocks to the common superloop of their successors; when a block is moved up the hierarchy, we add its predecessors to the queue to process. However, when the predecessor of bb already belongs to a loop higher in the hierarchy, we do not put it to the queue (since the change at bb obviously cannot affect the placement of the predecessor). This gets slightly more complicated by the need to handle subloops; in the described heuristics, we were mistakenly comparing the position of the predecessor with the subloop, instead of with the loop to that the subloop was moved.
