Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796]

[Jakub Jelinek <jakub@redhat.com>]

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