[Bug c/50521] -fstrict-volatile-bitfields is not strict

["henrik at henriknordstrom dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521

--- Comment #14 from Henrik NordstrÃm <henrik at henriknordstrom dot net> 2011-10-29 10:45:53 UTC ---
(In reply to comment #13)

> > See 7.1.7.5 second and third paragraph and the note just after.
> 
> Is that means a statement
>   a = b;
> always should be treat as if
>   tmp = b;
>   a = tmp;
> two individual statements?

That's my understanding of the text.

Further, given

struct {
   volatile int bits:32;
} a;
int result;

my understanding is that the note means that

  result = ++a.bits;

should be translated into

  int tmp = a.bits;
  a.bits = tmp + 1;
  result = a.bits;

and a++ into

  result = a.bits;
  tmp = a.bits;
  a.bits = tmp + 1;

suitable expanded for aligned container loads & stores on each access to
a.bits, with each access to the a container int handled as a volatile access.

Also, from in the second sentence of the note the load of the container on
write may not be optimized away even if it's entirely masked by the write
operation. I.e. 

a.bits = x;

translates into

  int tmp = *(int *)(int aligned address of a.bits);
  tmp &= ~0xFFFFFFFF;
  tmp |= x;
  *(int *)(int aligned address of a.bits) = tmp;

which is the same load & store memory access sequence as used when a.bits is
not filling the entire container.

  int tmp = *(int *)(int aligned address of a.bits);
  tmp &= ~a_bits_mask;
  tmp |= (x << shift) & ~a_bits_mask;
  *(int *)(int aligned address of a.bits) = tmp;

where it's not allowed to optimize away the initial load if the result of that
load is entirely masked away by the bit-field assignment (32 bit ~0xFFFFFFFF ==
0). Operations on tmp between the load & store of the a.bits container may be
optimized freely as tmp itself is not a volatile.

> I think STRICT_ALIGNMENT is not only for ARM, but also MIPS, SH and others.
> I'll create new ticket later about STRICT_ALIGNMENT.

agreed

none of this is only about ARM I think. But the ARM AAPCS specification is
suitable to use as reference for the implementation as it's very detailed on
how to operate on volatile bit-fields and also alignment requirements on
bit-field accesses in general. Not sure the others are as detailed, and it's
very likely the rules from the ARM specification can be applied there as well.