From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9263 invoked by alias); 31 Oct 2013 09:40:25 -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 9251 invoked by uid 89); 31 Oct 2013 09:40:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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; Thu, 31 Oct 2013 09:40:23 +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 r9V9eLNY021786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Oct 2013 05:40:21 -0400 Received: from redhat.com (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9V9eHcf020309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 31 Oct 2013 05:40:20 -0400 Date: Thu, 31 Oct 2013 11:12:00 -0000 From: Marek Polacek To: Mike Stump Cc: Jason Merrill , GCC Patches Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation Message-ID: <20131031094017.GG31396@redhat.com> References: <20131025165803.GF27400@redhat.com> <526AB5CC.60408@redhat.com> <20131025190356.GG27400@redhat.com> <526AC0C9.1050003@redhat.com> <20131030145253.GB31396@redhat.com> <52712C29.3010206@redhat.com> <20131030161504.GC31396@redhat.com> <8CFC1A6E-0922-4F40-A9D4-14C2E9F8E848@comcast.net> <20131030221548.GD31396@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-10/txt/msg02667.txt.bz2 On Wed, Oct 30, 2013 at 03:41:53PM -0700, Mike Stump wrote: > The dtors only run, after the ctors run. We mark where the ctors finish spot, as the _start_ of the region for which we have to clean up. Really, the cleanup has nothing to do with ctors. You can have dtors, without any ctors, or ctors, without any dtors. > > { > decl d; > s; > } > > transforms into: > > <----- start of lifetime of the storage for d > ctor(d) > <----- start of lifetime of the fully constructed object d > s; > <----- end of lifetime of fully constructed object d > dtor(d) > <----- end of the storage of d > > CLEANUP_STMT documents when the region protected by the cleanup starts. One want to describe that region is, the end of the ctors, if any, else after the storage is allocated. In the above, that is the second <---- spot. > > Now, in the trees, the above is decl d; ctors; CLEANUP_STMT (s, dtors, d). > > s is the region for which the cleanups are active for. dtors is the cleanup to perform on transfer out of that region, and d is the decl related to the actions in dtors. I see now. Thanks very much, Mike. Marek