+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.
On Thu, Feb 18, 2021 at 7:51 PM yao zhongxiao via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I had the issue related to abi compatibility while using gcc > 10;
> here is the changelog, hope to be helpful.
>
> https://gcc.gnu.org/gcc-10/changes.html
>
> ```
>
> - The ABI of passing and returning certain C++ classes by value
> changed on several targets in GCC 10, including AArch64
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383>, ARM
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711>, PowerPC
ELFv2
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707>, S/390
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704> and Itanium
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706>. These
changes
> affect classes with a zero-sized subobject (an empty base class, or data
> member with the [[no_unique_address]] 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 -std=c++17 and -std=c++20 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 -std=c++17 and -std=c++14 ABI incompatible. This has been
> corrected and the empty bases are ignored in those ABI decisions, so
> functions compiled with -std=c++14 and -std=c++17 are now ABI
> compatible again. Example: struct empty {}; struct S : empty { float
> f; }; void f(S);. Similarly, in classes containing non-static data
> members with empty class types using the C++20 [[no_unique_address]]
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 -Wpsabi.
>
> ```
>
> --
> Name: zhongxiao yao
> Email: zhongxiao.yzx at gmail.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/d7e5b6f7/attachment.html>