From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57985 invoked by alias); 18 Nov 2015 13:39:27 -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 57975 invoked by uid 89); 18 Nov 2015 13:39:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f173.google.com Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 18 Nov 2015 13:39:25 +0000 Received: by ykdr82 with SMTP id r82so62791871ykd.3 for ; Wed, 18 Nov 2015 05:39:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.125.137 with SMTP id y131mr1666720ywc.5.1447853963435; Wed, 18 Nov 2015 05:39:23 -0800 (PST) Received: by 10.37.93.11 with HTTP; Wed, 18 Nov 2015 05:39:23 -0800 (PST) In-Reply-To: <1948174.ZHELUNJJpu@polaris> References: <1750746.G8iFFmz9eE@polaris> <1948174.ZHELUNJJpu@polaris> Date: Wed, 18 Nov 2015 13:39:00 -0000 Message-ID: Subject: Re: [patch] Fix PR middle-end/65958 From: Richard Biener To: Eric Botcazou Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02206.txt.bz2 On Wed, Nov 18, 2015 at 12:12 PM, Eric Botcazou wrote: >> Ok. I wonder if we document GCCs VLA implementation somewhere so we can add >> a note on the interaction with alloca. > > I found this in 10.7.2 Blocks: > > "Variable-length arrays (VLAs) complicate this process, as their size > often refers to variables initialized earlier in the block. To handle > this, we currently split the block at that point, and move the VLA into > a new, inner `BIND_EXPR'. This strategy may change in the future." > > which sounds totally obsolete to me. Proposed change: Looks good to me. I also found the Arrays of Variable Length section in extend.texi which also refers to alloca as doing the same. We may want to add a note there that you should not mix both and that only VLAs (when not mixed with alloca) are freed at scope boundary. Richard. > Index: doc/generic.texi > =================================================================== > --- doc/generic.texi (revision 230453) > +++ doc/generic.texi (working copy) > @@ -1950,11 +1950,15 @@ this initialization replaces the @code{D > will never require cleanups. The scope of these variables is just the > body > > -Variable-length arrays (VLAs) complicate this process, as their > -size often refers to variables initialized earlier in the block. > -To handle this, we currently split the block at that point, and > -move the VLA into a new, inner @code{BIND_EXPR}. This strategy > -may change in the future. > +Variable-length arrays (VLAs) complicate this process, as their size > +often refers to variables initialized earlier in the block and their > +initialization involves an explicit stack allocation. To handle this, > +we add an indirection and replace them with a pointer to stack space > +allocated by means of @code{alloca}. In most cases, we also arrange > +for this space to be reclaimed when the enclosing @code{BIND_EXPR} is > +exited, the exception to this being when there is an explicit call to > +@code{alloca} in the source code, in which case the stack is left > +depressed on exit of the @code{BIND_EXPR}. > > A C++ program will usually contain more @code{BIND_EXPR}s than > there are syntactic blocks in the source code, since several C++ > > > -- > Eric Botcazou