This is the mail archive of the
mailing list for the GCC project.
RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "sandra at codesourcery dot com" <sandra at codesourcery dot com>, "dj at redhat dot com" <dj at redhat dot com>
- Date: Tue, 3 Sep 2013 11:23:28 +0200
- Subject: RE: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets
- Authentication-results: sourceware.org; auth=none
- References: <DUB122-W35943644A5D83EC2CAFDB7E4370 at phx dot gbl>,<52245D01 dot 1030702 at arm dot com>,<Pine dot LNX dot 4 dot 64 dot 1309021600390 dot 17654 at digraph dot polyomino dot org dot uk>,<CAFiYyc0he723Zn7jhpXxZCuhL+=KkmDU5FWHvjDpC4juJcsvvg at mail dot gmail dot com>
On Tue, 3 Sep 2013 10:30:22, Richard Biener wrote:
> On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers <email@example.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.
>> Joseph S. Myers