From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15421 invoked by alias); 11 Feb 2013 10:00:48 -0000 Received: (qmail 15278 invoked by uid 48); 11 Feb 2013 10:00:21 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/56264] [4.8 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557 Date: Mon, 11 Feb 2013 10:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg01040.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264 --- Comment #4 from Richard Biener 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.