From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5565 invoked by alias); 30 Oct 2013 22:16:01 -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 5552 invoked by uid 89); 30 Oct 2013 22:16:00 -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; Wed, 30 Oct 2013 22:15:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9UMFqHu029477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 18:15:52 -0400 Received: from redhat.com (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9UMFm8T025393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 18:15:51 -0400 Date: Wed, 30 Oct 2013 22:46:00 -0000 From: Marek Polacek To: Mike Stump Cc: Jason Merrill , GCC Patches Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation Message-ID: <20131030221548.GD31396@redhat.com> References: <20130925124132.GJ12296@redhat.com> <52697B9D.9000502@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CFC1A6E-0922-4F40-A9D4-14C2E9F8E848@comcast.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-10/txt/msg02616.txt.bz2 Thanks Mike. I had a quick look at the CLEANUP_STMT and cp-tree.def says "A CLEANUP_STMT marks the point at which a declaration is fully constructed.", while doc says "Used to represent an action that should take place upon exit from the enclosing scope. Typically, these actions are calls to destructors for local objects." Huh? So, how come it e.g. initializes variables, and on the other hand it should run dtors? I'm baffled (but it's too late for me to think clearly ;)). Marek