From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20561 invoked by alias); 30 Mar 2012 13:27:28 -0000 Received: (qmail 20546 invoked by uid 22791); 30 Mar 2012 13:27:26 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_CF 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; Fri, 30 Mar 2012 13:27:03 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/52756] [4.8 Regression] 255.vortex in SPEC CPU 2000 failed to build Date: Fri, 30 Mar 2012 13:43: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: 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: 2012-03/txt/msg02666.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52756 --- Comment #4 from Richard Guenther 2012-03-30 13:26:57 UTC --- (In reply to comment #3) > DOM jump threading threads the loop latch edge: > > if (latch->aux) > { > /* First handle the case latch edge is redirected. */ > loop->latch = thread_single_edge (latch); > gcc_assert (single_succ (loop->latch) == tgt_bb); > loop->header = tgt_bb; At this point everything is still ok, but > /* Thread the remaining edges through the former header. */ > thread_block (header, false); this creates a multiple entry loop (with the old entry being an unreachable block after threading - sth cfgcleaup exposes, which in turn would turn that into a valid loop, albeit with bogus header/latch, again). Now, thread_through_loop_header ensures (fingers crossing) that we never create a multiple entry loop. Thus the following fix would work. Index: gcc/tree-ssa-threadupdate.c =================================================================== --- gcc/tree-ssa-threadupdate.c (revision 186007) +++ gcc/tree-ssa-threadupdate.c (working copy) @@ -649,6 +649,17 @@ thread_block (basic_block bb, bool noloo || THREAD_TARGET2 (e)))) continue; + /* thread_through_loop_header made sure we are not creating + a multiple entry loop. If we are creating a new loop + entry the destination will become the new header of the + loop and the old entry will become unreachable. */ + if (e->src->loop_father != e2->dest->loop_father) + { + e2->dest->loop_father->header = e2->dest; + /* Discard knowledge about the latch. */ + e2->dest->loop_father->latch = NULL; + } + if (e->dest == e2->src) update_bb_profile_for_threading (e->dest, EDGE_FREQUENCY (e), e->count, THREAD_TARGET (e));