* [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] @ 2022-03-30 10:07 Jakub Jelinek 2022-03-30 11:00 ` Richard Biener 2022-03-30 12:10 ` Richard Earnshaw 0 siblings, 2 replies; 6+ messages in thread From: Jakub Jelinek @ 2022-03-30 10:07 UTC (permalink / raw) To: gcc-patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] 2022-03-30 10:07 [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] Jakub Jelinek @ 2022-03-30 11:00 ` Richard Biener 2022-03-30 11:30 ` Jakub Jelinek 2022-03-30 12:10 ` Richard Earnshaw 1 sibling, 1 reply; 6+ messages in thread From: Richard Biener @ 2022-03-30 11:00 UTC (permalink / raw) To: Jakub Jelinek; +Cc: GCC Patches 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] 2022-03-30 11:00 ` Richard Biener @ 2022-03-30 11:30 ` Jakub Jelinek 2022-10-22 16:47 ` Gerald Pfeifer 0 siblings, 1 reply; 6+ messages in thread From: Jakub Jelinek @ 2022-03-30 11:30 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Patches 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] 2022-03-30 11:30 ` Jakub Jelinek @ 2022-10-22 16:47 ` Gerald Pfeifer 0 siblings, 0 replies; 6+ messages in thread From: Gerald Pfeifer @ 2022-10-22 16:47 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Richard Biener, gcc-patches 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>, ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] 2022-03-30 10:07 [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] Jakub Jelinek 2022-03-30 11:00 ` Richard Biener @ 2022-03-30 12:10 ` Richard Earnshaw 2022-03-30 12:13 ` Richard Earnshaw 1 sibling, 1 reply; 6+ messages in thread From: Richard Earnshaw @ 2022-03-30 12:10 UTC (permalink / raw) To: Jakub Jelinek, gcc-patches 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] 2022-03-30 12:10 ` Richard Earnshaw @ 2022-03-30 12:13 ` Richard Earnshaw 0 siblings, 0 replies; 6+ messages in thread From: Richard Earnshaw @ 2022-03-30 12:13 UTC (permalink / raw) To: Jakub Jelinek, gcc-patches 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 >> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-10-22 16:47 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-03-30 10:07 [wwwdocs] Document zero width bit-field passing ABI changes in gcc-12/changes.html [PR104796] Jakub Jelinek 2022-03-30 11:00 ` Richard Biener 2022-03-30 11:30 ` Jakub Jelinek 2022-10-22 16:47 ` Gerald Pfeifer 2022-03-30 12:10 ` Richard Earnshaw 2022-03-30 12:13 ` Richard Earnshaw
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).