[patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

Bernd Edlinger bernd.edlinger@hotmail.de
Tue Sep 3 09:23:00 GMT 2013


On Tue, 3 Sep 2013 10:30:22, Richard Biener wrote:
> On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
>> On Mon, 2 Sep 2013, Richard Earnshaw wrote:
>>
>>> On 01/09/13 14:10, Bernd Edlinger wrote:
>>>> IMHO the AAPCS forbids packed structures. Therefore we need not
>>>> interfere with the C++ memory model if we have unaligned data.
>>>
>>> The AAPCS neither forbids nor requires packed structures. They're a GNU
>>> extension and as such not part of standard C++. Thus the semantics of
>>> such an operation are irrelavant to the AAPCS: you get to chose what the
>>> behaviour is in this case...
>>
>> The trouble is that AAPCS semantics are incompatible with the default GNU
>> semantics for non-packed structures as well - AAPCS
>> strict-volatile-bitfields is only compatible with --param
>> allow-store-data-races=1, which is not the default for any language
>> variant accepted by GCC (and I say that the default language semantics
>> here should not depend on the target architecture).
>
> As I said it should be easy to fulfil AAPCS requirements if they do not violate
> language constrains during code generation and thus warn about accesses
> that are emitted in a way not conforming to AAPCS (a warning at struct
> declaration time would be nicer, but I guess requires more coding and thought,
> though at the point we compute DECL_BIT_FIELD_REPRESENTATIVE in
> stor-layout.c would be a suitable place).
>

Just to make that clear, Sandra's patch tries to follow the AAPCS requirements,
_even if_ they violate the language constraints.

Thus -fstrict-volatile-bitfields implies --param allow-store-data-races=1.

Bernd.

> Richard.
>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com 		 	   		  


More information about the Gcc-patches mailing list