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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 30 14:31:49 PST 2015


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.

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

struct Y {
  char : 1;
  __attribute__((aligned(1))) int n : 24;
} y = { 0x010203 };

struct Z {
  char : 1;
  __attribute__((aligned(1))) int n : 25;
} z = { 0x010203 };

gives:

y:
        .zero   1
        .byte   3
        .byte   2
        .byte   1
z:
        .zero   4
        .byte   3
        .byte   2
        .byte   1
        .byte   0

... and if the structs are packed, y is unchanged and z changes to this:

z:
        .zero   1
        .byte   3
        .byte   2
        .byte   1
        .byte   0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151130/9d21439b/attachment.html>


More information about the cfe-commits mailing list