| Message ID | 20200507090851.GL8462@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | wwwdocs: Document the C++ ABI changes in GCC 10 | expand |
On 07/05/20 11:08 +0200, Jakub Jelinek wrote: >Hi! > >This is my humble attempt to document the C++ ABI changes. >Or do you have something better? >Not sure e.g. how C++ calls the TREE_ADDRESSABLE types which are >passed/returned by invisible reference, perhaps it would be nice >to make it clear that those aren't affected. > >As the release tarballs contain a copy of changes.html, I'm afraid >we need to resolve this before I can roll the tarballs. > >--- htdocs/gcc-10/changes.html 2020-05-07 10:44:17.391465227 +0200 >+++ htdocs/gcc-10/changes.html 2020-05-07 11:02:50.580691123 +0200 >@@ -31,6 +31,27 @@ a work-in-progress.</p> > <h2>Caveats</h2> > <ul> > <li> >+ <a name="empty_base">The ABI</a> >+ of passing and returning certain C++ classes by value changed >+ on several targets in GCC 10, including AArch64, ARM, PowerPC ELFv2, >+ S/390 and Itanium. In <code>-std=c++17</code> and <code>-std=c++20</code> >+ modes for classes with empty bases which otherwise contain only a single >+ element or are handled as homogeneous aggregates in >+ <code>-std=c++14</code> and earlier modes the existence of the empty >+ bases resulted in those classes not to be considered as having a single >+ element or be homogeneous aggregate and so could be passed differently, >+ making <code>-std=c++17</code> and <code>-std=c++14</code> compiled code >+ ABI incompatible. This has been corrected and the empty bases are >+ ignored in those ABI decisions, so <code>-std=c++14</code> and >+ <code>-std=c++17</code> compiled codes are now again ABI compatible. >+ Example: <code>struct empty {}; struct S : public empty { float f; }</code>. >+ Similarly, in classes containing non-static data members with empty >+ class types and with C++20 <code>[[no_unique_address]]</code> attribute >+ those members weren't ignored in the ABI argument passing decisions >+ as they should be. Both of these ABI changes are now diagnosed with >+ <code>-Wpsabi</code>. >+ </li> >+ <li> > The deprecated Profile Mode and <code>array_allocator</code> extensions > have been removed from libstdc++. > </li> Here's what I've committed after discussion on IRC, combining Jakub's text with what I had.
--- htdocs/gcc-10/changes.html 2020-05-07 10:44:17.391465227 +0200 +++ htdocs/gcc-10/changes.html 2020-05-07 11:02:50.580691123 +0200 @@ -31,6 +31,27 @@ a work-in-progress.</p> <h2>Caveats</h2> <ul> <li> + <a name="empty_base">The ABI</a> + of passing and returning certain C++ classes by value changed + on several targets in GCC 10, including AArch64, ARM, PowerPC ELFv2, + S/390 and Itanium. In <code>-std=c++17</code> and <code>-std=c++20</code> + modes for classes with empty bases which otherwise contain only a single + element or are handled as homogeneous aggregates in + <code>-std=c++14</code> and earlier modes the existence of the empty + bases resulted in those classes not to be considered as having a single + element or be homogeneous aggregate and so could be passed differently, + making <code>-std=c++17</code> and <code>-std=c++14</code> compiled code + ABI incompatible. This has been corrected and the empty bases are + ignored in those ABI decisions, so <code>-std=c++14</code> and + <code>-std=c++17</code> compiled codes are now again ABI compatible. + Example: <code>struct empty {}; struct S : public empty { float f; }</code>. + Similarly, in classes containing non-static data members with empty + class types and with C++20 <code>[[no_unique_address]]</code> attribute + those members weren't ignored in the ABI argument passing decisions + as they should be. Both of these ABI changes are now diagnosed with + <code>-Wpsabi</code>. + </li> + <li> The deprecated Profile Mode and <code>array_allocator</code> extensions have been removed from libstdc++. </li>