On Fri, 10 Jan 2020 01:02:23 +1100
John Adriaan via Std-Discussion <std-discussion_at_[hidden]> wrote:

> A. Given the above definitions, accesses to :
>
> a. f1 are 8-bit oriented;
> b. f2 are 8-bit oriented.
>
> B. If I change the definition of B to "typedef bool B;" (for
> ONLY this scenario), accesses to :
>
> a. f1 are 8-bit oriented;
> b. f2 are 8-bit oriented.
>
> C. If I un-comment (ONLY) the "Optional 7" line, then accesses
> to :
>
> a. f1 are 8-bit oriented;
> b. f2 are 16-bit oriented.
>
> D. If I un-comment (ONLY) the "Optional 15" line, then
> accesses to :
>
> a. f1 are 8-bit oriented;
> b. f2 are 32-bit oriented.
>
> E. In each of the above examples, if I ALSO un-comment the
> "Optional 0" line, then accesses in each case don't change.

What GCC did you try this with? I get totally different behaviour. I
tested locally with an ARM GCC 9.1.0, and in gcc.godbolt.org with ARM
GCC 8.3.1. In every single case, accessing a field whose type is bool
(so f1 always or f2 in case B) used LDRB (byte-oriented), while
accessing a field whose type is unsigned (so f2 except in case B) used
LDR (32-bit-oriented).

https://gcc.godbolt.org/z/STgeTa

So while I haven’t thought through the proposal enough to fully comment
on its merits, it does seem to me that the behaviour of GCC, for ARM at
least, is based 100% on the type of the field, and seems to be
unaffected by other fields in the struct. And that seems like what the
documentation for -fstrict-volatile-bitfields suggests should happen,
too, if I understand it correctly (and you did say it should be set).

-- 
Christopher Head