From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23279 invoked by alias); 4 Nov 2011 11:40:09 -0000 Received: (qmail 23270 invoked by uid 22791); 4 Nov 2011 11:40:08 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_TM 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; Fri, 04 Nov 2011 11:39:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA4Bdnnx014802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Nov 2011 07:39:49 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pA4Bdmf2017508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2011 07:39:49 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id pA4Bdm6Y029587; Fri, 4 Nov 2011 12:39:48 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id pA4BdlhG029585; Fri, 4 Nov 2011 12:39:47 +0100 Date: Fri, 04 Nov 2011 12:28:00 -0000 From: Jakub Jelinek To: Michael Matz Cc: gcc-patches@gcc.gnu.org Subject: Re: Mark objects death at end of scope Message-ID: <20111104113947.GK1052@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <20111103093336.GW1052@tyan-ft48-01.lab.bos.redhat.com> <20111103113722.GY1052@tyan-ft48-01.lab.bos.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00538.txt.bz2 On Thu, Nov 03, 2011 at 02:07:31PM +0100, Michael Matz wrote: > In this specific case we could notice that resx1 actually is the outermost > resume, hence only will leave the function and therefore the clobber is > useless (as in, moving them down actually removes them from the function > body). But suppose the whole code above would itself be contained in some > other region to which the resx1 would lead. We could move the clobber > there (and to the fall thru path that skips that region, which is the case > with catch region), that it safe (outer cleanup regions are always outer > or following scopes, and moving clobber outwards or lower is > conservatively correct), but extends the life area of the variables in > question. Well, for just the clobber stmts followed by resx that isn't caught in the function at least we definitely shouldn't catch it, do nothing and rethrow. struct POD { char a[10]; }; extern void bar (POD *); extern void baz (); void foo (bool cond) { if (cond) { POD pod; bar (&pod); } baz (); } I'd certainly hope we don't generate here any catch/rethrow (similarly for non-PODs with trivial dtors). > The other possibility would be removing the clobbers (all of them) right > before ehcleanup2 (shortly before expand) and somehow remember the edges > over which the variables die. That seems a bit fragile as there are some > more passes between them that fiddle with edges. Can't you, if you detect only clobber stmts followed up by rethrow, just move the clobber stmts to where the throw would be caught resp. remove if not caught? Jakub