[Bug middle-end/50527] inconsistent vla align

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2011-09-27 11:08:01 UTC ---
On Tue, 27 Sep 2011, vries at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50527
> 
> --- Comment #6 from vries at gcc dot gnu.org 2011-09-27 10:49:23 UTC ---
> > I think we can check if the size is constant in evaluate_stmt and
> > compute alignment according to that.  
> 
> We can only do that in the last ccp phase that does folding of vla-alllocas.
> 
> If the argument is not constant, it will not be folded in this phase, but it
> might be folded during the next ccp phase, when the argument does turn
> constant.
> 
> If the argument is constant, it might not be folded in this phase, but it still
> might be folded during the next ccp phase.
> 
> Therefore, in evaluate_stmt, we cannot predict whether the alloca will be
> folded, unless we're in the last ccp phase. And the propagation of alignment of
> alloca starts in the first ccp phase.
> 
> > It should only change from
> > non-constant to constant, thus properly go down the lattice during
> > propagation.
> 
> Currently, the result of an alloca is always constant, to be precise, constant
> 0 with only lower bits valid. This is independent of whether the argument is
> constant.

The parameter I meant.  But yes if we don't fold alloca in ccp1
we might fold away alignment tests based on BIGGEST_ALIGNMENT while
later ccp might fold it and use less alignment.  Maybe don't assume
any particular alignment for allocas for vlas then.

Richard.