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 jos...@codesourcery.com
