> We use the container mode where possible.
> It is always possible for well-formed bit-fields.
This is the only part I really need.
> If necessary the user has to add anonymous bit field members, or
> convert normal members to bit-fields.
IIRC I added code to support normal members as well, the "bitfields"
part of the option name is not entirely accurate.
> But when the bit field is conflict with the either the hardware's alignment
> requirements or with the C++11 memory model, we follow the latter.
Fine with me.
> 2. we allow unaligned packed data, but we may use multiple accesses
> for a single read/write op. Also in this case: no data store races
> outside the member.
We should note that volatile != atomic in these cases. Perhaps a
warning would be in order?
> Example:
>
> struct {
> volatile int a : 24;
> volatile char b;
> };
>
> This is not well-formed, and -fstrict-volatile-bitfields will have
> no effect on it.
I agree this isn't well-formed, but -fs-v-b could still make a best
effort since none of the fields *individually* span a natural
boundary.
> The user has to re-write this structure to:
>
> struct {
> volatile int a : 24;
> volatile char b : 8;
> };
More accurate would be these:
struct {
volatile int a : 24;
volatile int b : 8; /* overlap, should be the same type */
};
struct {
volatile int a : 24;
volatile int : 0;
volatile char b; /* no overlap, make the padding explicit */
};
