Re: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 2/2

[DJ Delorie <dj at redhat dot com>]

> I'm curious; do all the test cases included in
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
> work for you on those targets as well (without applying the rest of the 
> patch)?

Not all of them can work, because they describe something that can't
be done in hardware.  For example, the first test has an incomplete
bitfield - the fields do not completely describe an "int" so the
structure is smaller (one byte, according to sizeof()) than the access
type (2-8 bytes).

Looking through the tests, most of them combine "packed" with
mismatched types.  IMHO, those tests are invalid.

> > Either way, if -fstrict-volatile-bitfields does not do what it's
> > supposed to do, the correct action is to fix it - not to disable it on
> > targets that rely on it for correct operation.
> 
> Unfortunately, "fixing" -fstrict-volatile-bitfields to conform to the 
> AAPCS breaks conformance with the C11/C++11 standards,

The global default is -fno-strict-volatile-bitfields.  The flag was
added specifically to force the compiler to always use the
user-specified type when accessing bitfields, at least when it was
physically possible.  I don't see why there's a problem.  Without the
flag, you follow the standard.  With the flag, you do what the user
told you to do.  It's up to the targets to decide which way the flag
defaults if the user doesn't specify.  For my targets, the default
must be to do what the user told you to do, regardless of the
standards, because the standards lead to hardware failure.

> Meanwhile, while we're bickering about what the default should be,
> ARM users (in particular) are stuck in a situation where GCC's
> default behavior is to generate unaligned accesses that fault at
> runtime or wrong code that silently truncates bitfields,

Note that if the user defines a structure that intentionally mixes
types in a hardware word, the compiler can't "do what it's told".
It's still up to the user to write well-defined structures in those
cases.  Mixing packed, incomplete bitfields, and multiple types,
(i.e. pr48784-1.c in that patch) is an example of a case where gcc
can't do what the user asked, because what the user asked is nonsense.

> and there is *no* command-line option or even build-time option they
> can provide to make GCC generate code that is correct according to
> the AAPCS.

At the time I added -fstrict-volatile-bitfields, the ARM maintainers
seemed to agree that the new functionality was what they needed.  So,
-fstrict-volatile-bitfields *is* that command line option, it's just
either broken for them, or they're trying to do something not
physically possible.

> But, looking at it practically, I think the battle over
> "correctness" was already over when the C and C++ standards
> committees voted to specify this behavior in a particular way, and
> that in time ABIs that specify some other behavior are going to be
> either revised or considered archaic or obsolete.

My problem isn't some arbitrary ABI, it's a hardware peripheral
register that just can't be accessed in the wrong mode, because the
peripheral won't work if you do that.  Most MCU peripherals work this
way.  Just reading a byte or word outside the intended one could have
real consequences in the hardware.

> About the only way forward I can see is if the GCC steering
> committee steps in with a general policy statement about what to do
> when language standards conflict with a target ABI.

I've not objected to fixing -fstrict-volatile-bitfields, or making the
-fno-strict-volatile-bitfields case match the standard.  I've only
objected to breaking my targets by making that flag not the default.