------- Comment #6 from alexandre dot nunes at gmail dot com 2007-11-02 16:58
-------
>From the gcc internals
(http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html):
Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree record_type)
This target hook returns true if bit-fields in the given record_type are to
be laid out following the rules of Microsoft Visual C/C++, namely: (i) a
bit-field won't share the same storage unit with the previous bit-field if
their underlying types have different sizes, and the bit-field will be aligned
to the highest alignment of the underlying types of itself and of the previous
bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole
enclosing structure, even if it is unnamed; except that (iii) a zero-sized
bit-field will be disregarded unless it follows another bit-field of nonzero
size. If this hook returns true, other macros that control bit-field layout are
ignored.
When a bit-field is inserted into a packed record, the whole size of the
underlying type is used by one or more same-size adjacent bit-fields (that is,
if its long:3, 32 bits is used in the record, and any additional adjacent long
bit-fields are packed into the same chunk of 32 bits. However, if the size
changes, a new field of that size is allocated). In an unpacked record, this is
the same as using alignment, but not equivalent when packing.
If both MS bit-fields and `__attribute__((packed))' are used, the latter
will take precedence. If `__attribute__((packed))' is used on a single field
when MS bit-fields are in use, it will take precedence for that field, but the
alignment of the rest of the structure may affect its placement.
... it seems like that the packed attribute has the power of nulify the
ms_struct attribute, but not the gcc_struct one, regarding a rather non-uniform
behaviour if the underlying ABIs are different. It also means that I could use
ms_struct,packed in a portable way (even on architetures where the ms_struct
isn't even an alternative), but gcc_struct,packed is less portable. Right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
