On 06/17/2013 02:27 PM, Julian Brown wrote:
> On Mon, 17 Jun 2013 13:38:05 +0200
> Richard Biener <richard.guent...@gmail.com> wrote:
>
>> On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
>> <jul...@codesourcery.com> wrote:
>>> IIUC, the incompatibility between the specified
>>> -fstrict-volatile-bitfields behaviour and the C++ memory model is a
>>> recognised deficiency in the ARM EABI. It might be an unpopular
>>> suggestion, but how about disabling the option by default for C++ on
>>> ARM [*]? Maybe even with a "sorry" if the user tries to turn it on
>>> manually?
>>
>> How are they incompatible? As far as I understand the
>> -fstrict-volatile-bitfields
>> at most restricts the size of the access further, no? Can you write
>> down an example that shows the incompatibility? (woudl be nice to
>> see that as comment before the relevant code).
>
> Well -- I'm certainly no expert on the C++ memory model, but I am under
> the impression (that I can't seem to verify by googling ;-)) that
> accesses to adjacent bitfields during volatile access of a particular
> bitfield are forbidden. So simply, for the following:
>
> struct foo {
> int a : 8;
> int b : 8;
> int c : 16;
> };
>
> volatile struct foo x;
>
> void bar (void) { x.b++; }
>
> to satisfy the ARM EABI, 'bar' will access all three of a, b and c
> using read-modify-write (using int-sized accesses). IIUC for the C++
> memory model, only 'b' may be accessed, e.g. using byte-sized
> loads/stores.
The one I came up with after reading about the C++ memory model spec is
struct x
{
int x: 8;
char : 0;
short y : 8;
} z;
I interpret the C++ rules to say that due to the zero-sized bitfield, x
and y are different memory locations, and modifying one shouldn't affect
the other. However, with -fstrict-volatile-bitfields, x must be accessed
as an int, so it overlaps y.
> I'm quite prepared to be wrong though, in which case sorry for the
> noise :-).
Same here :)
Bernd
