patch [6/5] check for conflict with -fstrict-volatile-bitfields and -std=

[Joseph S. Myers]

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