From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20782 invoked by alias); 23 Aug 2012 11:00:56 -0000 Received: (qmail 20766 invoked by uid 22791); 23 Aug 2012 11:00:52 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Aug 2012 11:00:31 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos Date: Thu, 23 Aug 2012 11:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: 2012-08/txt/msg01605.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #20 from rguenther at suse dot de 2012-08-23 11:00:29 UTC --- On Thu, 23 Aug 2012, rguenther at suse dot de wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 > > --- Comment #17 from rguenther at suse dot de 2012-08-23 09:19:04 UTC --- > On Thu, 23 Aug 2012, steven at gcc dot gnu.org wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 > > > > --- Comment #16 from Steven Bosscher 2012-08-23 08:53:04 UTC --- > > (In reply to comment #15) > > > Makes me wonder why the loop isn't recognized in the original test case... > > > > Ah, maybe because bb3 has an abnormal predecessor and is therefore ignored as a > > potential loop header? > > > > /* If we have an abnormal predecessor, do not consider the > > loop (not worth the problems). */ > > if (bb_has_abnormal_pred (header)) > > continue; > > > > Which brings things back to my question why this kind of loop header is > > rejected! :-) > > Because gimple_split_edge doesn't like to split abnormal edges, > called via force_single_succ_latches (). So we do definitely > not allow abnormal latch -> header edges. Still abnormal loop entries > should be fine. So, > > Index: gcc/cfgloop.c > =================================================================== > --- gcc/cfgloop.c (revision 190613) > +++ gcc/cfgloop.c (working copy) > @@ -400,24 +400,21 @@ flow_loops_find (struct loops *loops) > { > edge_iterator ei; > > - /* If we have an abnormal predecessor, do not consider the > - loop (not worth the problems). */ > - if (bb_has_abnormal_pred (header)) > - continue; > - > FOR_EACH_EDGE (e, ei, header->preds) > { > basic_block latch = e->src; > > - gcc_assert (!(e->flags & EDGE_ABNORMAL)); > - > /* Look for back edges where a predecessor is dominated > by this block. A natural loop has a single entry > node (header) that dominates all the nodes in the > loop. It also has single back edge to the header > from a latch node. */ > if (latch != ENTRY_BLOCK_PTR > - && dominated_by_p (CDI_DOMINATORS, latch, header)) > + && dominated_by_p (CDI_DOMINATORS, latch, header) > + /* We cannot make latches simple by splitting the > + latch -> header edge if the latch edge is abnormal. */ > + && (single_succ_p (latch) > + || !(e->flags & EDGE_ABNORMAL))) > { > /* Shared headers should be eliminated by now. */ > SET_BIT (headers, header->index); > > should "work". But doesn't fix the testcase (of course). Btw, another idea would be to make labels that are target of abnormal edges end a basic-block. That way you'd have the edges "pre-split". Richard.