<div dir="ltr">+Richard & John in case there's anything we need to do on the Clang side to ensure Clang is consistent with whichever ABI decision GCC took here.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 18, 2021 at 7:51 PM yao zhongxiao via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I had the issue related to abi compatibility while using gcc > 10;</div><div>here is the changelog, hope to be helpful.</div><div><br></div><a href="https://gcc.gnu.org/gcc-10/changes.html" target="_blank">https://gcc.gnu.org/gcc-10/changes.html</a><div><br></div><div>```</div><div><ul style="color:rgb(0,0,0);font-family:"PingFang SC";font-size:medium"><li><a id="gmail-m_-5499408772829925969empty_base">The ABI</a> of passing and returning certain C++ classes by value changed on several targets in GCC 10, including <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383" style="color:rgb(0,102,187);text-decoration-line:none" target="_blank">AArch64</a>, <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711" style="color:rgb(0,102,187);text-decoration-line:none" target="_blank">ARM</a>, <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707" style="color:rgb(0,102,187);text-decoration-line:none" target="_blank">PowerPC ELFv2</a>, <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704" style="color:rgb(0,102,187);text-decoration-line:none" target="_blank">S/390</a> and <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706" style="color:rgb(0,102,187);text-decoration-line:none" target="_blank">Itanium</a>. These changes affect classes with a zero-sized subobject (an empty base class, or data member with the <code>[[no_unique_address]]</code> attribute) where all other non-static data members have the same type (this is called a "homogeneous aggregate" in some ABI specifications, or if there is only one such member, a "single element"). In <code>-std=c++17</code> and <code>-std=c++20</code> modes, classes with an empty base class were not considered to have a single element or to be a homogeneous aggregate, and so could be passed differently (in the wrong registers or at the wrong stack address). This could make code compiled with <code>-std=c++17</code> and <code>-std=c++14</code> ABI incompatible. This has been corrected and the empty bases are ignored in those ABI decisions, so functions compiled with <code>-std=c++14</code> and <code>-std=c++17</code> are now ABI compatible again. Example: <code>struct empty {}; struct S : empty { float f; }; void f(S);</code>. Similarly, in classes containing non-static data members with empty class types using the 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></ul></div><div>```<br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Name: zhongxiao yao<div>Email: <a href="mailto:zhongxiao.yzx@gmail.com" target="_blank">zhongxiao.yzx@gmail.com</a></div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>