On Tue, 3 Sep 2013 21:20:04, Joseph S. Myers wrote: > 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. >
I fully agree with you, the current default state of -fstrict-volatile-bitfields should be disabled for all targets. That will be changed in part 4 of Sandra's patch. For portability of application code, the default should be always off, unless specifically requested. Even driver code rarely uses bit-fields for register access, because that is inherently non-portabe. Reason: the bit positions are completely different on little- and big-endian targets. Most drivers I have seen use some macros and explicit bit operations for register accesses. > -- > Joseph S. Myers > jos...@codesourcery.com
