| Summary: | VLA breaks alloca() | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Alexandre Oliva <aoliva> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bruno, gcc-bugs, msebor, sds |
| Priority: | P2 | Keywords: | diagnostic, documentation, patch |
| Version: | 3.3.2 | ||
| Target Milestone: | --- | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Known to work: | 7.0 |
| Known to fail: | Last reconfirmed: | 2005-12-24 19:46:05 | |
| Attachments: | Testcase that exposes the problem. | ||
|
Description
Alexandre Oliva
2004-02-21 10:36:24 UTC
Created attachment 5780 [details]
Testcase that exposes the problem.
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}.)
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. 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").
Maybe there is a need for more docs. Some how I missed the patch but here it is: <http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02092.html>. *** Bug 19881 has been marked as a duplicate of this bug. *** (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. 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. (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. |