[patch] Fix PR middle-end/65958

[Eric Botcazou]

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

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