On Mon, Nov 30, 2015 at 11:33 AM, John McCall <rjmcc...@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
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits