[llvm-dev] Utilising no-unique-address

[yao zhongxiao via llvm-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210219/346d010c/attachment.html>