Fix PR middle-end/65958

> 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:

On Wed, Nov 18, 2015 at 12:12 PM, Eric Botcazou <ebotcazou@adacore.com> 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

> 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.

It's already there and in fact the current behavior is documented:

 There are other differences between these two methods.  Space allocated
with `alloca' exists until the containing _function_ returns.  The
space for a variable-length array is deallocated as soon as the array
name's scope ends.  (If you use both variable-length arrays and
`alloca' in the same function, deallocation of a variable-length array
also deallocates anything more recently allocated with `alloca'.)

so we need to amend the documentation if we go for the patch.

On Wed, Nov 18, 2015 at 3:28 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> 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.
>
> It's already there and in fact the current behavior is documented:
>
>  There are other differences between these two methods.  Space allocated
> with `alloca' exists until the containing _function_ returns.  The
> space for a variable-length array is deallocated as soon as the array
> name's scope ends.  (If you use both variable-length arrays and
> `alloca' in the same function, deallocation of a variable-length array
> also deallocates anything more recently allocated with `alloca'.)
>
> so we need to amend the documentation if we go for the patch.

Ah.  I think the patch is good and we should reflect this in the
documentation.

Richard.

> --
> Eric Botcazou

> Ah.  I think the patch is good and we should reflect this in the
> documentation.

OK, will do, thanks.