http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
vries at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vries at gcc dot gnu.org
--- Comment #7 from vries at gcc dot gnu.org 2011-10-11 10:45:04 UTC ---
> OK, I didn't realize that things were still ongoing on this front.
There was still a bug lingering: PR50527, an inconsistency between actual
alignment after folding and alignment propagated by ccp.
That got us to rethink the alignment for allocas. Using the alloca_with_align,
we can transport the DECL_ALIGN of the vla decl to:
- the alloca folding, where we can use it on the replacement decl, and
- expand_builtin_alloca where we can lower the required alignment passed to
allocate_dynamic_stack_space
The latter means that we change something also when we're not folding allocas.
> Frankly, this alloca folding seems to introduce far too much complication for
> what it's worth.
> Tom, did you consider reverting the whole thing and doing things differently?
> If your canonical example is something like:
>
> const int n = 5;
> int array[n];
>
> it's very easy to fold this in the front-end into:
>
> const int n = 5;
> int array[5];
I think I tried that in the beginning, but didn't manage to get that working.
But apart from that, doing it in the front-end doesn't take care of more
complicated examples, f.i. where the array size only becomes constant after
inlining.
I'm now trying to reproduce this failure on x86_64.
