Re: [patch 3/5] don't restrict bit range for -fstrict-volatile-bitfields

[Sandra Loosemore <sandra at codesourcery dot com>]

On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
> On Mon, 17 Jun 2013, Julian Brown wrote:
>
> > IIUC, the incompatibility between the specified
> > -fstrict-volatile-bitfields behaviour and the C++ memory model is a
> > recognised deficiency in the ARM EABI. It might be an unpopular
> > suggestion, but how about disabling the option by default for C++ on
> > ARM [*]? Maybe even with a "sorry" if the user tries to turn it on
> > manually?
>
> The C11 and C++11 memory models are the same, this is nothing to do with
> C++ as opposed to C.
>
> Someone from ARM will need to answer as to what their plans are to make
> AAPCS compatible with the memory model.  I'd say strict-volatile-bitfields
> should only ever apply in cases where it does not conflict with language
> semantics - so just as "packed" should take precedence, so the memory
> model should also take precedence (in the absence of --param
> allow-store-data-races=1, anyway) in those cases where AAPCS would
> indicate writing to an object outside the maximal sequence of consecutive
> non-zero-width bit-fields.

The problem with always choosing C++ memory model compliance over ABI 
compliance, no matter what the setting of -fstrict-volatile-bitfields, 
is that some users may have legacy code out there where they really want 
the ABI-compliant behavior.  Perhaps we should not make 
-fstrict-volatile-bitfields not be the default on any target any more, 
but if you supply it explicitly it tells GCC that you really want the 
ABI-compliant behavior to override the language-standard-compliant behavior?

I don't think there's an actual conflict there between 
-fstrict-volatile-bitfields and packed structure extensions.  AAPCS 
allows for the possibility of packed structures but says conforming 
programs don't use them for external interfaces (this is the note at the 
end of 7.1.7.1).  As I noted previously, my understanding is that the 
volatile access requirements in the AAPCS only apply to non-packed 
struct fields whose layout and alignment is fully specified by AAPCS. 
The various packed-structure bugs addressed by part 4 of my patch series 
are mostly cases where the required single access *cannot* be emitted 
because the field is not aligned; instead, we're emitting code that is 
totally wrong even under GCC's normal access rules, because it faults at 
runtime or only accesses part of the bit-field.

-Sandra