[Bug middle-end/50527] inconsistent vla align

["vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527

--- Comment #3 from vries at gcc dot gnu.org 2011-09-27 09:21:12 UTC ---
> Or alternatively (given we re-compute alignment together with folding alloca),
> assign the same alignment as folding would.

At the point that we determine the alloca alignment during propagation in
visit_stmt, we cannot predict whether that alloca will be folded (during the
same or later ccp phase).

So the only way to achieve other alignment is to be conservative a bit longer
for vla-allocas with respect to alignment:
- keep align at 1 byte during ccp.
- if we fold during ccp, assign align calculated at folding
- after we are sure there is no more folding (at expand, or f.i. at the end of
  the second ccp phase if we limit folding to the first 2 ccp phases, to take
  advantage of the larger alignment in the middle-end), we assign
  BIGGEST_ALIGNMENT.

> The question is of course what standards say about the alignment of
> alloca (4)

I think alloca is non-standard. But in the context of
fold_builtin_alloca_for_var, alloca is the implementation vehicle of vlas, so
the question is what the standard says about alignment of vlas.