> Ah. I think the patch is good and we should reflect this in the
> documentation.
OK, will do, thanks.
--
Eric Botcazou
On Wed, Nov 18, 2015 at 3:28 PM, Eric Botcazou wrote:
>> Looks good to me. I also found the Arrays of Variable Length section
>> in extend.texi which also refers to alloca as doing the same. We may
>> want to add a note there that you should not mix both and that only
>> VLAs (when not mixed wit
> Looks good to me. I also found the Arrays of Variable Length section
> in extend.texi which also refers to alloca as doing the same. We may
> want to add a note there that you should not mix both and that only
> VLAs (when not mixed with alloca) are freed at scope boundary.
It's already there
On Wed, Nov 18, 2015 at 12:12 PM, Eric Botcazou wrote:
>> 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 refe
> 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,
On Wed, Nov 18, 2015 at 11:06 AM, Eric Botcazou wrote:
> Hi,
>
> this is the underlying issue of PR middle-end/65958: the compiler generates
> wrong code when alloca is used in conjunction with a VLA since the latter
> causes the stack space allocated to the former to be wrongly reclaimed.
> So th
Hi,
this is the underlying issue of PR middle-end/65958: the compiler generates
wrong code when alloca is used in conjunction with a VLA since the latter
causes the stack space allocated to the former to be wrongly reclaimed.
So the proposed fix is not to reclaim any stack space in this case.
B
