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

[DJ Delorie]

I'm starting from an MCU that doesn't work right if GCC doesn't do
what the user tells GCC to do.  I added -fstrict-volatile-bitfields to
tell gcc that it needs to be more strict than the standard allows for
bitfield access, because without that flag, there's no way to force
gcc to use a specific access width on bitfields.  When I added that
flag, some ARM folks chose to enable it in their target, because they
felt they needed it.  If different ARM folks feel otherwise, that's a
target problem.

If the user tells gcc that a particular 32-bit memory location should
be treated as both a char and a long, then gcc has been given
inconsistent information.  The spec says it can do what it wants to
access that memory, and it does.

If the user tells gcc that a particular 16-bit memory location
consists of 16-bits worth of "unsigned short", and the user has told
gcc that it needs to be strict about accessing that field in the type
specified, and gcc uses a 32-bit access anyway, gcc is wrong.

I will agree with you 100% that gcc can do whatever the spec allows if
the user does NOT specify -fstrict-volatile-bitfields, but the flag is
there to tell gcc that the user needs stricter control than the spec
demands.  If the user uses that flag, *and* gives gcc information that
is inconsistent with the use of that flag, then the user is wrong.

I note that you assume GNU/Linux is involved, perhaps that's part of
the problem.  Maybe the Linux kernel needs gcc to ignore its bitfield
types, but other ARM firmware may have other requirements.  If you and
the other ARM maintainers want to argue over whether
-fstrict-volatile-bitfields is enabled by default for the ARM target,
go for it.  Just leave my targets alone.

> where those semantics contradict the semantics of ISO C.

Where in the spec does it say that a compiler MUST access an "unsigned
short" bitfield with a 32-bit access?  I've seen places where it says
the compiler MAY or MIGHT do it, but not MUST.