Utilising no-unique-address

I had the issue related to abi compatibility while using gcc > 10;
here is the changelog, hope to be helpful.


- 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`.

+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.