From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1137 invoked by alias); 11 Feb 2013 10:28:15 -0000 Received: (qmail 1087 invoked by uid 48); 11 Feb 2013 10:27:57 -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:28: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/msg01046.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56264 --- Comment #5 from Richard Biener 2013-02-11 10:27:56 UTC --- I would guess that originally cfg-cleanup caused basic-blocks to leak outside a loop, thus at most exposing new use sites. With discovering new loops we may both wreck that scheme (loop depth may not change but blocks still leak) and fail to recognize use-blocks of defs that changed loop ownership. Fix_loop_structure could return the number of newly discovered loops, indicating that the whole function needs to be re-scanned (still not accounting for weird loop tree hierarchy changes, but those shouldn't be caused by transformations cfgcleanup does). Testing a patch.