http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-11 10:00:18 UTC --- unswitching makes the formerly irreducible inner loop reducible on one path (cfgcleanup makes this loop appear). As we are in the loop optimizer block we are supposed to be in loop-closed SSA. Now we only mark a single block as changed (bb 7, the loop header of the newly recognized inner loop). rewrite_into_loop_closed_ssa functions in the way that it only scans changed_bbs for out-of-def-loop _uses_. I don't see how that can catch all changes detected by (even former) fix_loop_structure which marks blocks as changed whose loop depth changes (that is, if a definition block changes its loop depth but the use block does not, like in this case, we fail to fixup loop-closed SSA form). Not sure if "no new loops are discovered" excluded this possibility in the old scheme. Now, the block with the use that needs a loop-closed PHI node at the exit of the newly discovered loop isn't changed in any way (nor is the exit block). That said - I still fail to see the logic of the old computation of "changed-blocks" in fix_loop_structure. I'd said we need to re-scan all loop blocks of loops we exit to from loops that have 'changed blocks'. And maybe all loop blocks we may exit from to a loop that has 'changed blocks'. Hmmmm.
