[PATCH, PR50527] Don't assume alignment of vla-related allocas.

[Tom de Vries]

On 10/04/2011 10:58 PM, Richard Henderson wrote:
> On 10/04/2011 01:17 PM, Tom de Vries wrote:
>> In general, to fold vlas (which are lowered to allocas) to normal declarations,
>> if the alloca argument is constant.
> 
> Ah.  Ok, I suppose.  How often are you seeing this happening?  I can imagine
> a few instances via inlining, but even there not so much...
>

I have no statistics on this. But something simple like this is still translated
into a vla, and can be folded:
...
const int n = 5;
int array[n];
...

>> Any guidance on what to do if we have to expand the __builtin_alloca_with_align
>> to a function call, specifically, with the second argument? This is currently
>> handled like this, which is not very nice:
> 
> Don't do anything special.  Just let it fall through as with alloca.  This should
> never happen, except for stupid user tricks like -fno-builtin-alloca_with_align.
> And if the user does that, they get what they deserve wrt needing to implement
> that function in their runtime.
> 

What currently causes this behaviour, is -fmudflap, see mf_xform_statements in
tree-mudflap.c. The patch handles handles __builtin_allloca_with_align the same
as __builtins_alloca in that function, meaning that both are marked with
gimple_call_set_cannot_inline.

So:
- we always expand alloca_with_align in expand_builtin_alloca, even for
  -fmudflap, or
- we need to handle the expansion of the call, or
- ... ?

Thanks,
- Tom

> 
> r~