https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79209
--- Comment #5 from Pekka S <p...@gcc-bugzilla.mail.kapsi.fi> --- It's true what you quoted, but on the other hand the current behaviour does not produce code that will not fault -- it will indeed fault. I see the rationale behind the packed attribute applied to a structure (say, the attached structure has a default alignment of 4) so the compiler may generate access that is narrower (or has a smaller alignment) that what it would be normally be (at least with strict alignment) for whatever reason. However, bitfields are not marked volatile and -fstrict-volatile-bitfield is not used just for nothing. So when it says "it may not be possible to access the field with a single read or write [...]" I don't why it wouldn't be possible to use access that has a greater alignment requirement (on a strict aligment platform -- although it's actually run-time configurable on AArch64) than what the structure has with the packed attribute (reduced to the minimum, i.e. 1) set. Now, it could be argued, that with the packed attribute one could still force narrower volatile bitfield accesses if -fstrict-volatile-bitfield is used (I can't think of any reason why one would, but still), but currently even that is not possible as the accesses are not consistent. Also, what is the most misleading in this case is that -fstrict-volatile-bitfield "should use a single access of the width of the field's type" and I guess everyone agrees that packed attribute has nothing to do with width of the field's type, at least with attached structure and alike. So, perhaps inheritably by language design width and alignment are used somewhat interchangeably, even though they are not. Maybe this falls a bit inside the undefined behaviour land, but again, a warning message would suffice, if the behaviour is not going to be changed to inform the user that his mileage may vary.
