[PATCH] D14980: PR18513: make gcc compatible layout for bit-fields with explicit aligned attribute

[John McCall via cfe-commits]

On Mon, Nov 30, 2015 at 2:31 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Mon, Nov 30, 2015 at 11:33 AM, John McCall <rjmccall at gmail.com> wrote:
>
>> rjmccall added a comment.
>>
>> In http://reviews.llvm.org/D14980#298754, @rsmith wrote:
>>
>> > GCC's behavior (`aligned` on a field specifies the alignment of the
>> start of that field) makes a little more sense to me than Clang's behavior
>> (the type and alignment of a field specify a flavour of storage unit, and
>> the field goes in the next such storage unit that it fits into), but both
>> seem defensible.
>>
>>
>> Are you saying that `aligned` on a bit-field always starts new storage on
>> GCC?
>
>
> Not exactly. For instance, given
>
> struct X {
>   __attribute__((aligned(1))) char a : 2, b : 2, c : 2, d : 2;
> } x = {0, 1, 2, 3};
>
> ... GCC produces
>
> x:
>         .byte   0
>         .byte   1
>         .byte   2
>         .byte   3
>
> The result is the same for any other bit-field type (except that we get
> tail padding for types wider than 4 bytes), and in particular, we don't
> allocate a new storage unit for 'b' and 'd' when the type is 'short'; we
> just insert padding to get to a 1-byte-aligned boundary.
>

This is what I meant by starting new storage: it never fills space in the
previous byte.  And now I realize that of course that's the major effect of
this patch.

The rule that a bit-field can't straddle a naturally-aligned storage unit
> for the underlying type still applies (for non-packed structs).
>

This is going to require significant surgery to this function.  And it
looks like this rule should apply to ms_struct layout as well.

In other words:
  - The offset of the field is rounded up to the next multiple of the
explicit alignment that (unless the field is packed) does not cause the
field to straddle its natural alignment boundary, which can happen if its
explicit alignment is less than its natural alignment.
  - On platforms (like ARM) that ignore the natural alignment of
bit-fields, this seems to have no effect except to always start a new
byte.  We seem to be getting this wrong, too.
  - Both the field's natural alignment and its explicit alignment, as
capped by the max field alignment, contribute to the alignment of the
aggregate, unless the field is packed.  Again, currently wrong.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151130/d4fc6f23/attachment.html>