On Mon, Jun 17, 2013 at 2:38 PM, Bernd Schmidt <ber...@codesourcery.com> wrote:
> 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.
True. IIRC the char : 0 isn't even necessary for the limitation to take
place (just the different underlying types is enough).
> However, with -fstrict-volatile-bitfields, x must be accessed
> as an int, so it overlaps y.
Ok, that's a good example then. Looking at the mode of the FIELD_DECL
for x isn't a good way to query the access mode then, but the mode
of DECL_BIT_FIELD_TYPE would. Note that for z.x you are not guaranteed
to end up with a COMPONENT_REF at RTL expansion time at all but it
may be lowered to a MEM_REF by arbitrary optimization passes (unlikely
because most simply go away when they see a volatile access), because
it's bitsize is a multiple of BITS_PER_UNIT and it's boundary is byte-aligned.
Richard.
>> I'm quite prepared to be wrong though, in which case sorry for the
>> noise :-).
>
> Same here :)
>
>
> Bernd
>
