Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

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

> Note that the exact same effect would happen if alloca was not a
> builtin.

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.

Regards,
Martin