On Wed, 19 Jun 2013, Sandra Loosemore wrote: > On 06/17/2013 06:02 PM, Sandra Loosemore wrote: > > > > I had another thought: perhaps -fstrict-volatile-bitfields could remain > > the default on targets where it currently is, but it can be overridden > > by an appropriate -std= option. Perhaps also GCC could give an error if > > -fstrict-volatile-bitfields is given explicitly with an incompatible > > -std= option. > > Like this. This patch is intended to be applied on top of the other 5 pieces > in this series, although in theory it's independent of them. OK to commit, > and does this resolve the objection to part 3?
I don't think it's right to depend on the standard version like this. The existing semantics for GNU C and C++ follow the memory model for all standard versions, and that's the sort of thing that shouldn't depend on the target architecture. In the absence of explicit -fstrict-volatile-bitfields, semantics conflicting with the memory model should only be enabled by one of the --param options to allow data races, and not by some default option relating to something in a target ABI that's incompatible with the normal language semantics. -- Joseph S. Myers jos...@codesourcery.com
