This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
> 
>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]