This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Tue, 3 Sep 2013, Bernd Edlinger wrote:

> >> 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.

And my concern is specifically about the defaults - the default for ARM 
should be the same C/C++ language as on other targets - rather than what 
happens if someone specifies -fstrict-volatile-bitfields explicitly.

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]