https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- 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 this to be implemented as aligning the array type but not its element type?
