[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #10)
> On Wed, 7 Feb 2018, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
> > 
> > --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > I think the bug is in the ARRAY_REF design, because at least in C one can have
> > arrays of over-aligned types the design choice that ARRAY_REF TREE_OPERAND (,
> > 3)
> > is measured in multiplies of TYPE_ALIGN_UNIT of the element doesn't make sense,
> > because what you really get from array_ref_element_size in cases where the size
> > of element is not a multiple of the TYPE_ALIGN_UNIT is something that doesn't
> > have anything to do with the element size.
> > Is that some Ada specific stuff?
> > Similarly component_ref_field_offset multiplies by DECL_OFFSET_ALIGN,
> > supposedly in this case DECL_OFFSET_ALIGN of b shouldn't be 16 bytes, but
> > something smaller.
> 
> It is an optimization so that for variable-sized stuff it's easier to
> get at an alignment value.  We've experimented with removing this
> but it regressed some cases (even in C).  Eric may know more and I
> think there was a bug tracking this ... or some ml posts.
> 
> So arrays of over-aligned types in C do not contain padding?  Thus
> the elements are not aligned but only the first element?  Wasn't

I believe so.

> this to be implemented as aligning the array type but not its element
> type?

Not sure how it would be possible.  There is the debug info question (perhaps
not a show stopper with early debug), another one is that for aggregates the
alignment is an essential part, we don't have for the same aggregate
differently aligned variants.  And we can have arrays of arrays, or arrays of
VLA structures etc.

Anyway, seems with the _Alignas(16) or __attribute__((aligned (16))) before the
struct keyword we actually don't have array of over-aligned fields, that is
what you get when using struct __attribute__((aligned (16))) { short aa; }
a[size];

That is somewhat simpler case, it is only the array field itself that is
aligned, array_ref_element_size is not involved at all in that case, but we
still compute an incorrect rli->offset_align somewhere for the b field.
While the previous field is 16 bytes aligned, the element is only 2 bytes
aligned and variable size, so b is only guaranteed to be 4 bytes aligned (2
bytes if it was say char b[size];).