Bug 14236 - VLA breaks alloca()
VLA breaks alloca()
Status: NEW
Product: gcc
Classification: Unclassified
Component: middle-end
3.3.2
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
: diagnostic, documentation, patch
: 19881 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-21 10:36 UTC by Alexandre Oliva
Modified: 2005-12-24 19:46 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-12-24 19:46:05


Attachments
Testcase that exposes the problem. (386 bytes, text/plain)
2004-02-21 10:37 UTC, Alexandre Oliva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Oliva 2004-02-21 10:36:24 UTC
If the same block contains a dynamically-sized array and alloca() calls, we
release the memory allocated for both at the end of the block.  Oops.  This
occurs in GCC 3.3.3, 3.4 CVS, mainline CVS and tree-ssa CVS (oh, and GCC 2.96 as
well, but you don't want to know about that :-)

Optimization doesn't seem to affect it.
Comment 1 Alexandre Oliva 2004-02-21 10:37:46 UTC
Created attachment 5780 [details]
Testcase that exposes the problem.
Comment 2 Joseph S. Myers 2004-02-21 10:56:34 UTC
Subject: Re:  New: dynamically-sized arrays break
 alloca()

On Sat, 21 Feb 2004, aoliva at gcc dot gnu dot org wrote:

> If the same block contains a dynamically-sized array and alloca() calls, we
> release the memory allocated for both at the end of the block.  Oops.  This
> occurs in GCC 3.3.3, 3.4 CVS, mainline CVS and tree-ssa CVS (oh, and GCC 2.96 as
> well, but you don't want to know about that :-)

So where's the bug in this?  It looks just like what the documentation
says:

# (If you use both variable-length arrays and
# @code{alloca} in the same function, deallocation of a variable-length array
# will also deallocate anything more recently allocated with @code{alloca}.)

Comment 3 Alexandre Oliva 2004-02-22 00:06:08 UTC
Well, yes, it is documented, but that doesn't make it right (although I know
people that will qualify documented bugs as features :-).  IMHO, it's still
wrong, especially now that variable-length arrays are standard.  Sure, alloca is
non-standard, but it still doesn't feel right.
Comment 4 Andrew Pinski 2004-02-23 00:40:40 UTC
On at least PPC (and most likely all other targets), alloca and VLAs is done by growing the stack and the 
restorting it (for the VLA case) at the end of the block.  I do not think there is anyways around this 
problem ("bug", "feature").
Comment 5 Andrew Pinski 2004-04-06 01:05:58 UTC
Maybe there is a need for more docs.
Comment 6 Andrew Pinski 2004-04-22 17:37:37 UTC
Some how I missed the patch but here it is:
<http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02092.html>.
Comment 7 Andrew Pinski 2005-02-10 20:53:10 UTC
*** Bug 19881 has been marked as a duplicate of this bug. ***
Comment 8 Sam Steingold 2005-02-10 21:13:43 UTC
(In reply to comment #3)
> Well, yes, it is documented, but that doesn't make it right (although I know
> people that will qualify documented bugs as features :-).  IMHO, it's still
> wrong, especially now that variable-length arrays are standard.  Sure, alloca is
> non-standard, but it still doesn't feel right.

why is this not right?
I find this perfectly natural.
Comment 9 Alexandre Oliva 2005-02-14 16:29:23 UTC
Yes, it is natural, once you look into the mechanisms used to implement the
features.  However, if you focus on the definitions:

- memory allocated for dynamic-sized arrays is released at the time the array
goes out of scope

- memory allocated with alloca() is released at the time the function that calls
alloca() returns

then there's no reason to expect dynamic-sized arrays and alloca() to interfere
with each other.

I agree that implementing them in such a way that they don't interfere is
probably impossible with a single stack, but that still doesn't make it right.
Comment 10 Sam Steingold 2005-02-14 17:47:12 UTC
(In reply to comment #9)
> - memory allocated with alloca() is released at the time the function that calls
> alloca() returns

oh - I didn't know that.
I always thought that alloca()ted memory is released by the next "}".
(i.e., identical to dynamic arrays).
Thanks for the clarification.