[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