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?
2. Or, should the snippet above add the padding?
Or, am I missing something?
Thanks.
