From patchwork Tue Jan 22 18:26:01 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 214611 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 1D6452C007B for ; Wed, 23 Jan 2013 05:26:36 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1359483997; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=3NjVwOoLocBuWPLZRZfH hhP2OFI=; b=eIFLFGpvvSTHUzaL+pY/4M1VKx4b0hh6zz+TjeRBf9p4ib4MjsgZ Qv9ctjn61gVI7K95ca2nWdTo2NBCUbmvPYIY2OHp2pQX59u7jT+SdLD/tKuNVCfa Xi8s/QLnupOVzRaTV3OcZqW5UbGNKGZsb+cnXPpZhoC/UcdnJMZzfw8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=FqEKkWxSmGoWfb26XzvHlVldPCTxEZxkJkJ20ntn/oiKgCyr/MIOVjtkSPWsFW qiW3GaUd+mpc+To+WiAOSmiB55I9dsiqGIq1OrV1eXXFCsz9QEqilU1Pw5RCJGiB wyMvgVBBEiBHnIYi3vQTtjJXnTlNUp5vWMF4eybVma6Xs=; Received: (qmail 28181 invoked by alias); 22 Jan 2013 18:26:15 -0000 Received: (qmail 28165 invoked by uid 22791); 22 Jan 2013 18:26:13 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS 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; Tue, 22 Jan 2013 18:26:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0MIQ5mP012292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jan 2013 13:26:06 -0500 Received: from redhat.com (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r0MIQ19t030243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 22 Jan 2013 13:26:04 -0500 Date: Tue, 22 Jan 2013 19:26:01 +0100 From: Marek Polacek To: Zdenek Dvorak Cc: GCC Patches , Richard Guenther Subject: Re: [PATCH] Fix PR56035 Message-ID: <20130122182601.GB12610@redhat.com> References: <20130122141300.GD18759@redhat.com> <20130122162601.GA18473@kam.mff.cuni.cz> <20130122172714.GE18759@redhat.com> <20130122174439.GA21864@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130122174439.GA21864@kam.mff.cuni.cz> User-Agent: Mutt/1.5.20 (2009-06-14) 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 On Tue, Jan 22, 2013 at 06:44:40PM +0100, Zdenek Dvorak wrote: > > I was however worried that we might end up with an edge > > coming out of BB > > from different loop heading into the header. In this case setting up > > loop's latch as the source of the latch edge would be wrong. > > Actually, the comment suggesting that possibility does not make much sense. > A latch (a predecessor of the header H that is dominated by H) belongs to > the loop headed by H by definition, so I am not quite sure what the test was supposed to do. > > The latch block may of course belong to a subloop of the loop, but that is not > forbidden (and it is taken care of further in fix_loop_structure through force_single_succ_latches > in the situations where we want to avoid this possibility), Well, okay then, thanks. So below is the new version of the patch. Regtested/bootstrapped on x86_64-linux again, ok for trunk? Richi, are you with this one? 2013-01-22 Marek Polacek * cfgloopmanip.c (fix_loop_structure): Remove redundant condition. * testsuite/gcc.dg/pr56035.c: New test. Marek --- gcc/cfgloopmanip.c.mp 2013-01-22 14:11:25.241233824 +0100 +++ gcc/cfgloopmanip.c 2013-01-22 19:00:39.850689745 +0100 @@ -1823,10 +1823,8 @@ fix_loop_structure (bitmap changed_bbs) /* If there was no latch, schedule the loop for removal. */ if (!first_latch) loop->header = NULL; - /* If there was a single latch and it belongs to the loop of the - header, record it. */ - else if (latch - && latch->src->loop_father == loop) + /* If there was a single latch, record it. */ + else if (latch) loop->latch = latch->src; /* Otherwise there are multiple latches which are eventually disambiguated below. */ --- gcc/testsuite/gcc.dg/pr56035.c.mp 2013-01-22 14:27:21.104614758 +0100 +++ gcc/testsuite/gcc.dg/pr56035.c 2013-01-22 14:31:01.642266091 +0100 @@ -0,0 +1,35 @@ +/* PR tree-optimization/56035 */ +/* { dg-do compile } */ +/* { dg-options "-O1 -ftree-vectorize -fcse-follow-jumps -fstrict-overflow" } */ + +short a, c, *p; + +void +f (void) +{ + int b; + + if (c) + lbl1: + for (a = 0; a < 1; a++) + { + for (c = 0; c < 1; c++) + { + goto lbl1; + while (*p++) + lbl2: + ; + } + } + + for (;; b++) + { + if (c) + goto lbl2; + lbl3: + for (c = 0; c < 9; c++) + for (c = -17; c < 2; c++) + if (*p) + goto lbl3; + } +}