diff mbox series

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

Message ID YkQr+9Z/MTSkeuJ4@tucnak
State New
Headers show
Series [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] | expand

Commit Message

Jakub Jelinek March 30, 2022, 10:07 a.m. UTC 
Hi!

This patch documents the PR102024 ABI changes.
The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
diagnostics.
Ok for wwwdocs?


	Jakub

Comments

Richard Biener March 30, 2022, 11 a.m. UTC | #1 
On Wed, Mar 30, 2022 at 12:08 PM Jakub Jelinek via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> Hi!
>
> This patch documents the PR102024 ABI changes.
> The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
> diagnostics.
> Ok for wwwdocs?
>
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 689feeba..dc0e4074 100644
> --- 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.

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,

struct X { long a0 : 24; long a1 : 8; long :0; long b0 : 24; long b1 : 8; };

struct X foo (struct X x)
{
  return x;
}

seem to pass in %rsi/%rdi and return in %rax/%rdx with both GCC 11 and trunk.

Richard.

>    <li>
>      <strong>C:</strong>
>      Computed gotos require a pointer type now.
>
>         Jakub
>
Jakub Jelinek March 30, 2022, 11:30 a.m. UTC | #2 
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
Richard Earnshaw March 30, 2022, 12:10 p.m. UTC | #3 
Doesn't this need the anchor that the compiler links to? 
#zero_width_bitfields

R.

On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote:
> Hi!
> 
> This patch documents the PR102024 ABI changes.
> The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
> diagnostics.
> Ok for wwwdocs?
> 
> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
> index 689feeba..dc0e4074 100644
> --- 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.
> +    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>
>     <li>
>       <strong>C:</strong>
>       Computed gotos require a pointer type now.
> 
> 	Jakub
>
Richard Earnshaw March 30, 2022, 12:13 p.m. UTC | #4 
Never mind, just spotted it.

:)



On 30/03/2022 13:10, Richard Earnshaw wrote:
> Doesn't this need the anchor that the compiler links to? 
> #zero_width_bitfields
> 
> R.
> 
> On 30/03/2022 11:07, Jakub Jelinek via Gcc-patches wrote:
>> Hi!
>>
>> This patch documents the PR102024 ABI changes.
>> The x86-64, ARM and AArch64 backends refer to this in their -Wpsabi
>> diagnostics.
>> Ok for wwwdocs?
>>
>> diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
>> index 689feeba..dc0e4074 100644
>> --- 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.
>> +    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>
>>     <li>
>>       <strong>C:</strong>
>>       Computed gotos require a pointer type now.
>>
>>     Jakub
>>
Gerald Pfeifer Oct. 22, 2022, 4:47 p.m. UTC | #5 
On Wed, 30 Mar 2022, Jakub Jelinek via Gcc-patches wrote:
> Thanks, changed and committed.

This (commit 3be1a28f58d6063258407b0751e8fb55df4749c8) introduced a new
<a name=...> which is deprecated HTML.

Below is the straightforward adjustment I just pushed.

Gerald


commit 95e5070662283453db934dee37203ce9db6e342c
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date:   Sat Oct 22 18:41:14 2022 +0200

    gcc-12: Replace an <a name=...> by an id=
    
    The name attribute for the <a> tag has been obsoleted. Use an id= on
    the nearest container instead, as we already do everywhere else.

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 0e56aba0..30fa4d6e 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -25,8 +25,7 @@ You may also want to check out our
 <!-- .................................................................. -->
 <h2>Caveats</h2>
 <ul>
-  <li>
-    An <a name="zero_width_bitfields">ABI</a> incompatibility between C and
+  <li id="zero_width_bitfields">An ABI incompatibility between C and
     C++ when passing or returning by value certain aggregates containing zero
     width bit-fields has been discovered on various targets.
     As mentioned in <a href="https://gcc.gnu.org/PR102024">PR102024</a>,
diff mbox series

Patch

diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 689feeba..dc0e4074 100644
--- 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.
+    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>
   <li>
     <strong>C:</strong>
     Computed gotos require a pointer type now.