This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 07 Feb 2018 12:19:15 +0000
- Subject: [Bug c/82210] [6/7/8 Regression] Having _Alignas in a struct with VLAs causes writing to one array to overwrite another
- Auto-submitted: auto-generated
- References: <bug-82210-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 7 Feb 2018, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82210
>
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |jakub at gcc dot gnu.org,
> | |rguenth at gcc dot gnu.org
>
> --- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> [Looping in the experts: Hi Jakub. Hi Richard.]
>
> Imagine this:
>
> struct big_container {
> __attribute__((aligned(16)))
> struct aa_container {
> short aa;
> } a[size];
> int b[size];
> } s;
>
> While laying out the type of big_container, and looking at field "a" in
> place_field() we get a DECL_SIZE_UNIT(a) of SAVE_EXPR <size> * 2 (courtesy of
> update_alignment_for_field).
>
> This size*2 is used in calculating the size of the record thus far:
>
> /* Now add size of this field to the size of the record. If the size is
> not constant, treat the field as being a multiple of bytes and just
> adjust the offset, resetting the bit position.
> ...
> else if (TREE_CODE (DECL_SIZE (field)) != INTEGER_CST
> || TREE_OVERFLOW (DECL_SIZE (field)))
> {
> rli->offset
> = size_binop (PLUS_EXPR, rli->offset,
> fold_convert (sizetype,
> size_binop (CEIL_DIV_EXPR, rli->bitpos,
> bitsize_unit_node)));
> rli->offset
> = size_binop (PLUS_EXPR, rli->offset, DECL_SIZE_UNIT (field));
> rli->bitpos = bitsize_zero_node;
> rli->offset_align = MIN (rli->offset_align, desired_align);
> }
>
> (gdb) p debug_generic_stmt(rli.offset)
> (sizetype) SAVE_EXPR <size> * 2;
>
> Which means that when we call place_field(b), we think we have to start at
> size*2. Surely the start of field b should take into consideration the
> alignment of aa_container, no?
>
> Question:
>
> 1. Should DECL_SIZE_UNIT(a) include the size of the alignment padding?
I'm not sure whether the attribute aligns the array elements or the
array. If it aligns the array then no.
> 2. Or, should the snippet above add the padding?
This is for b, so why? There should be no padding needed.
> Or, am I missing something?
>
> Thanks.
>
>