This is the mail archive of the
mailing list for the GCC project.
Re: Further observations regarding alloca on i586-pc-linux-gnu
- To: rth at cygnus dot com
- Subject: Re: Further observations regarding alloca on i586-pc-linux-gnu
- From: Martin von Loewis <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sun, 23 Aug 1998 20:20:05 +0200
- CC: carlo at runaway dot xs4all dot nl, egcs-bugs at cygnus dot com, pommnitz at darmstadt dot gmd dot de, egcs at cygnus dot com
- References: <firstname.lastname@example.org> <199808221724.TAA14230@jolan.ppro> <19980823043600.A4080@dot.cygnus.com>
> This is well known. What is not clear to me though, is whether
> it is a bug in the compiler or in the test.
I've tried to find documentation on the semantics of alloca in gcc,
but didn't found much. The portable alloca.c says
>> allocate automatically reclaimed memory
and this is how most users probably see it. extend.texi says that the
memory is available until the end of the function.
> The test is effectively relying on the order in which arguments are
> evaluated, which is wrong.
No, it doesn't. It requests memory reclaimed at the end of the
function. As it turns out, the compiler might overwrite the memory
> Note that the exact same effect would happen if alloca was not a
No, it wouldn't. The portable alloca would not reclaim the memory
until the next alloca call, and then only if the previous call was
deeper on stack.
> Note that if you mind sequence points like you ought, you get
> correct results.
The original example was using alloca as a default argument. It seems
that g++ currently does not support that, an alloca call must occur as
a full expression in itself, not inside a full expression.
So it seems g++ should either detect this violation in alloca usage,
or be fixed to support alloca in subexpressions.