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.
