Pascal, when I last spent quality time with the C++11 document I took away that:

- Much of the “sequenced before” and “sequenced after” language in the memory model applies both to inter-thread and intra-thread sequencing

- It is clearly intended that unsynchronized accesses to adjascent bitfields race

Of course I could be wrong in the details and will need to dig in again…

NOTE 2 A bit-field and an adjacent non-bit-field member are in separate memory locations. The same applies to two bit-fields, if one is declared inside a nested structure declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field member declaration. It is not safe to concurrently update two non-atomic bit-fields in the same structure if all members declared between them are also (non-zero-length) bit-fields, no matter what the sizes of those intervening bit-fields happen to be.

It says nothing about sequence points, only about concurrency.

Paragraph 2 in 6.5 says:

If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. [...]

This paragraph only speaks of scalar objects. A bit-field is not a scalar object. The meaning in 6.5 paragraph 2 would be clearer if it used “memory location” in place of “scalar object”, since “memory location” stands for “scalar object or contiguous sequence of bit-fields”.

With the current formulation, we can only infer that the intention was to forbid the posted program from the fact that unsequenced updates to the same bit-field are clearly forbidden. Technically speaking, 6.5:2 does not apply to bit-fields.

clang_delta is new and experimental, but works well already. Let me see what I can do to get it out there. Its in our internal SVN now, maybe we should just move it to github.