From patchwork Sat Mar 5 14:35:13 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 85527 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 2A654B70D1 for ; Sun, 6 Mar 2011 01:35:30 +1100 (EST) Received: (qmail 11963 invoked by alias); 5 Mar 2011 14:35:29 -0000 Received: (qmail 11684 invoked by uid 22791); 5 Mar 2011 14:35:27 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Mar 2011 14:35:18 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p25EZGqX024015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Mar 2011 09:35:17 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p25EZFSA017295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 09:35:15 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p25EZELx024951; Sat, 5 Mar 2011 15:35:14 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p25EZEcm024950; Sat, 5 Mar 2011 15:35:14 +0100 Date: Sat, 5 Mar 2011 15:35:13 +0100 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Cc: Zdenek Dvorak Subject: [committed] Fix get_loop_body ICE (PR rtl-optimization/47899) Message-ID: <20110305143513.GP30899@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! I've committed this patch of Zdenek to fix PR47899 after bootstrap/regtest on x86_64-linux and i686-linux to trunk, pre-approved in the PR. Zdenek, if you want to adjust the ChangeLog entry I've made up or use Jakub different e-mail address, just Change it in SVN. kam.uniff.cz domain you've used in your last two commits doesn't resolve... 2011-03-05 Zdenek Dvorak PR rtl-optimization/47899 * cfgloopmanip.c (fix_bb_placements): Fix first argument to flow_loop_nested_p when moving the loop upward. * gcc.dg/pr47899.c: New test. --- gcc/cfgloopmanip.c.jj 2010-11-03 10:48:15.000000000 +0100 +++ gcc/cfgloopmanip.c 2011-03-02 13:16:50.171526946 +0100 @@ -174,7 +174,7 @@ fix_bb_placements (basic_block from, { sbitmap in_queue; basic_block *queue, *qtop, *qbeg, *qend; - struct loop *base_loop; + struct loop *base_loop, *target_loop; edge e; /* We pass through blocks back-reachable from FROM, testing whether some @@ -214,12 +214,14 @@ fix_bb_placements (basic_block from, /* Subloop header, maybe move the loop upward. */ if (!fix_loop_placement (from->loop_father)) continue; + target_loop = loop_outer (from->loop_father); } else { /* Ordinary basic block. */ if (!fix_bb_placement (from)) continue; + target_loop = from->loop_father; } FOR_EACH_EDGE (e, ei, from->succs) @@ -248,9 +250,12 @@ fix_bb_placements (basic_block from, && (nca == base_loop || nca != pred->loop_father)) pred = pred->loop_father->header; - else if (!flow_loop_nested_p (from->loop_father, pred->loop_father)) + else if (!flow_loop_nested_p (target_loop, pred->loop_father)) { - /* No point in processing it. */ + /* If PRED is already higher in the loop hierarchy than the + TARGET_LOOP to that we moved FROM, the change of the position + of FROM does not affect the position of PRED, so there is no + point in processing it. */ continue; } --- gcc/testsuite/gcc.dg/pr47899.c.jj 2011-01-16 05:42:39.626675592 +0100 +++ gcc/testsuite/gcc.dg/pr47899.c 2011-03-02 13:23:02.675527008 +0100 @@ -0,0 +1,26 @@ +/* PR rtl-optimization/47899 */ +/* { dg-do compile } */ +/* { dg-options "-O -funroll-loops" } */ + +extern unsigned int a, b, c; +extern int d; + +static int +foo (void) +{ +lab: + if (b) + for (d = 0; d >= 0; d--) + if (a || c) + for (; c; c++) + ; + else + goto lab; +} + +int +main () +{ + foo (); + return 0; +}