https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> --- The only thing the x86-64 psABI says about this case is "'Unnamed bit-fields' types do not affect the alignment of a structure or union." . (zero-width bit-fields are _always_ unnamed) But the x86-64 psABI was written with the assumption in mind that zero-width bitfields influence the alignment of the following field (i.e. that they break the current bit bucket for two neighboring bitfield members). I.e. exactly what GCCs stor-layout.c code always did for these when not in microsoft compat mode. In the example in question this align-next-bitfield item doesn't come into play. But it does show that zero-width bitfields were designed and allowed as extension for a purpose. So it makes sense for instance on platforms that have a concept of homogenous aggregates that zero-width bit-fields disable those, without otherwise changing memory layout. So, I think, not removing those members from the FE makes sense, they contain crucial information. Unfortunately that means that they need to be dealt with in code dealing with layout (correct) or argument/return-value passing (seemingly fishy right now for some platforms?). Also, all else being equal I think the C language defines the de-facto psABI, so any difference between C and C++ should be resolved towards C.
