From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89700 invoked by alias); 9 Sep 2016 18:31:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 89676 invoked by uid 89); 9 Sep 2016 18:31:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=painful X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Sep 2016 18:31:33 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 89F6D7DD06; Fri, 9 Sep 2016 18:31:32 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-111.phx2.redhat.com [10.3.116.111]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u89IVV9g004022; Fri, 9 Sep 2016 14:31:32 -0400 Subject: Re: [PATCH 5/9] regrename: Don't run if function was separately shrink-wrapped To: Bernd Schmidt , Segher Boessenkool , gcc-patches@gcc.gnu.org References: Cc: dje.gcc@gmail.com From: Jeff Law Message-ID: <7e74a019-d477-348f-2dc6-744e1db38f2f@redhat.com> Date: Fri, 09 Sep 2016 18:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00534.txt.bz2 On 06/08/2016 03:18 AM, Bernd Schmidt wrote: > On 06/08/2016 03:47 AM, Segher Boessenkool wrote: >> + /* regrename creates wrong code for exception handling, if used >> together >> + with separate shrink-wrapping. Disable for now, until we have >> + figured out what exactly is going on. */ > > That needs to be figured out now or it'll be there forever. I suspect it's related to liveness computations getting out-of-wack with separate shrink wrapping. If that's the case, then the question in my mind is how painful is this going to be to fix in the df scanning code. jeff