On Wed, Mar 30, 2022 at 01:00:43PM +0200, Richard Biener wrote:
> > --- a/htdocs/gcc-12/changes.html
> > +++ b/htdocs/gcc-12/changes.html
> > @@ -28,6 +28,31 @@ a work-in-progress.</p>
> > <!-- .................................................................. -->
> > <h2>Caveats</h2>
> > <ul>
> > + <li>
> > + An <a name="zero_width_bitfields">ABI</a> incompatibility between C and
> > + C++ when passing or returning by value certain aggregates with zero
> > + width bit-fields has been discovered on various targets.
>
> "containing zero width bit-fields"?
>
> > + As mentioned in <a href="https://gcc.gnu.org/PR102024";>PR102024</a>,
> > + since the <a href="https://gcc.gnu.org/PR42217";>PR42217</a> fix in
> > + GCC 4.5 the C++ front-end has been removing zero width bit-fields
> > + from the internal representation of the aggregates after the layout of
> > those
> > + aggregates, but the C front-end kept them, so passing e.g.
> > + <code>struct S { float a; int : 0; float b; }</code> or
> > + <code>struct T { float c; int : 0; }</code> by value could differ
> > + between C and C++. Starting with GCC 12 the C++ front-end no longer
> > + removes those bit-fields from the internal representation and
> > + per clarified psABI some targets have been changed, so that they
> > + either ignore those bit-fields in the argument passing by value
> > + decisions in both C and C++, or they always take them into account.
> > + x86-64, ARM and AArch64 will always ignore them (so there is
> > + a C ABI incompatibility between GCC 11 and earlier with GCC 12 or
> > + later), PowerPC64 ELFv2 and S/390 always take them into account
> > + (so there is a C++ ABI incompatibility, GCC 4.4 and earlier compatible
> > + with GCC 12 or later, incompatible with GCC 4.5 through GCC 11).
> > + RISC-V has changed the handling of these already starting with GCC 10.
> > + GCC 12 on the above targets will report such incompatibilities as
> > + warnings or other diagnostics unless <code>-Wno-psabi</code> is used.
> > + </li>
>
> Otherwise LGTM.
Thanks, changed and committed.
> The case with float a; int :0; float b; looks quite artificial - are there
> cases
> where { int a0 : 24; int a1 : 8; int :0; int b0 : 24; int b1 : 8; }
> are affected? Thus
> cases where people might actually use :0 which is inbetween bitfields? At
> least I can't convince GCC on x86_64 to pass those differently,
on x86_64, we've actually been ignoring zero width bitfields on the 64-bit
word boundaries since forever due to the way how it was implemented:
/* Bitfields are always classified as integer. Handle them
early, since later code would consider them to be
misaligned integers. */
if (DECL_BIT_FIELD (field))
{
for (i = (int_bit_position (field)
+ (bit_offset % 64)) / 8 / 8;
i < ((int_bit_position (field) + (bit_offset % 64))
+ tree_to_shwi (DECL_SIZE (field))
+ 63) / 8 / 8; i++)
classes[i]
= merge_classes (X86_64_INTEGER_CLASS, classes[i]);
}
where the loop would do nothing when the bit_offset + int_bit_position is
64-bit aligned and DECL_SIZE (field) is integer_zerop.
So it was just the zero width bitfields at other offsets, and
those were treated as merging the containing 64-bit word with INTEGER class.
So, if there were just integer bitfields in that 64-bit word, merging
it with INTEGER class wouldn't change anything.
E.g. powerpc64le or s390x care about "homogenous" structures, whether
everything is float (or double?) and those bit-fields make it not
homogenous, so again one needs mixing float or double with : 0 bitfields
(which must be integral in C/C++).
So yes, it is hopefully rare if not non-existent in real-world code,
but apparently it has been already discovered before (in 2015 LLVM has been
changed on s390 to match the GCC C/C++ ABI incompatibility, and in GCC 10
riscv has been changed, unfortunately in neither case a discussion has been
held on whether that is intentional or not).
As for the remaining arches, I believe mips n32/n64 are effected and
fuzzy (they have a rule that if a 64-bit word in a struct is double
and isn't part of union, then it is passed in floating point regs,
otherwise in integer, and similarly to the non-clarified x86-64 psABI,
it is unclear if int :0 count in that and if they do, whether they
are part of the following or preceeding 64-bit word (as they live in a
boundary between them); then they have a rule that structures containing one
or two float members is returned one way, otherwise different, in that case
I'd say it is more like the ppc64le/s390x homogenous aggregate case),
loongarch probably should decide what they want,
ia64 and iq2000 are maybe effect but I really don't care about those,
and rest is hopefully unaffected.
Jakub
