it is violating the part of the spec that says that 'volitile' variables are assumed to be affected by external things and so the compiler cannot make assumptions that the variable has not changed just because it didn't issue any commands to change it.
remember, the developers are not demanding that the layout be a particular way, it's the compiler that's doing this.
restating my understanding
volitile int a;
and then making a change to b triggers a read/write cycle on a the compiler is doing the wrong thing (because the value of a may change between the read and write) and the programmer has explicitly told the compiler that a may change unexpectedly.
in the case that found the bug they were doing something like
and they found that if one thread modified the value of bitfield while another thread modified lock, the modification to lock would get lost.
If the compiler can't do 32 bit loads and stores, then it needs to store these two variables in a way that they are padded so that the 64 bit lodes and stores won't loose modifications.