<html><body><p><font size="2">Hi Jinsong,</font><br><br><font size="2">yes, exactly.  I was just trying a more complicated case:</font><br><br><font size="2">struct A {</font><br><font size="2">  int : 0;</font><br><font size="2">};</font><br><br><font size="2">struct B {</font><br><font size="2">  struct A a [[no_unique_address]];</font><br><font size="2">};</font><br><br><font size="2">struct C : B {</font><br><font size="2">  float f;</font><br><font size="2">};</font><br><br><font size="2">void f(C);</font><br><br><font size="2">void g(C *bp) {</font><br><font size="2">  f(*bp);</font><br><font size="2">}</font><br><br><font size="2">and this is not recognized as homogeneous aggregate right now.   (It is on Z with my patch.  It is also recognized by current GCC on both platforms.)</font><br><font size="2"><br><br>Mit freundlichen Gruessen / Best Regards<br><br>Ulrich Weigand<br><br>-- <br>  Dr. Ulrich Weigand | Phone: +49-7031/16-3727<br>  Distinguished Engineer, Open source compilers and toolchain<br>  IBM Deutschland Research & Development GmbH<br>  Vors. des Aufsichtsrats: Gregor Pillen | Geschäftsführung: Dirk Wittkopp<br>  Sitz d. Ges.: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294<br>  Data Privacy Statement der IBM: <a href="https://www.ibm.com/privacy/us/en/">https://www.ibm.com/privacy/us/en/</a></font><br><br><img width="16" height="16" src="cid:1__=4EBB0F0DDFC780318f9e8a93df938690918c4EB@" border="0" alt="Inactive hide details for Jinsong Ji---07.07.2020 17:03:10---Thanks Hubert.  This simple example may work for ppc64le, but I th"><font size="2" color="#424282">Jinsong Ji---07.07.2020 17:03:10---Thanks Hubert.  This simple example may work for ppc64le, but I think we still need to fix some othe</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Jinsong Ji/Jacksonville/IBM</font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">Hubert Tong <hubert.reinterpretcast@gmail.com></font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">Clang Dev <cfe-dev@lists.llvm.org>, LLVM Developers Mailing List <llvm-dev@lists.llvm.org>, "llvm-dev" <llvm-dev-bounces@lists.llvm.org>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">07.07.2020 17:03</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">Re: [EXTERNAL] Re: [llvm-dev] [RFC] C++20 ABI issue on several platforms</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><font size="2">Thanks Hubert. </font><br><br><font size="2">This simple example may work for ppc64le, but I think we still need to fix some other issues.</font><br><font size="2">eg: We do use isSingleElementStruct in getParamTypeAlignment as well.</font><br><br><font size="2"><br>Best,<br><br>Jinsong Ji (纪金松), PhD.<br><br>XL/LLVM on Power Compiler Development <br>E-mail: jji@us.ibm.com</font><br><br><br><img width="16" height="16" src="cid:1__=4EBB0F0DDFC780318f9e8a93df938690918c4EB@" border="0" alt="Inactive hide details for Hubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handl"><font size="2" color="#424282">Hubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handling already works for PPC64LE:</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">Hubert Tong via llvm-dev <llvm-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">Ulrich Weigand <Ulrich.Weigand@de.ibm.com></font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">LLVM Developers Mailing List <llvm-dev@lists.llvm.org>, Clang Dev <cfe-dev@lists.llvm.org></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">07/07/2020 10:25 AM</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">[EXTERNAL] Re: [llvm-dev] [RFC] C++20 ABI issue on several platforms</font><br><font size="2" color="#5F5F5F">Sent by:        </font><font size="2">"llvm-dev" <llvm-dev-bounces@lists.llvm.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>As information, it seems no_unique_address handling already works for PPC64LE:<tt><br>struct A {<br>  int : 0;<br>};<br><br>struct B {<br>  float f;<br>  struct A a [[no_unique_address]];<br>};<br><br>void f(B);<br><br>void g(B *bp) {<br>  f(*bp);</tt><br><tt>}</tt><br><br>Uses:<br><tt>lfsx 1, 0, 3</tt><br><br>Compiler Explorer link: <a href="https://godbolt.org/z/tHkSRQ"><u><font color="#0000FF">https://godbolt.org/z/tHkSRQ</font></u></a><br><br>On Tue, Jul 7, 2020 at 8:25 AM Ulrich Weigand via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a>> wrote:
<ul><font size="2">Hello,</font><br><font size="2"><br>as discussed here in more detail: </font><a href="https://reviews.llvm.org/D81583" target="_blank"><u><font size="2" color="#0000FF">https://reviews.llvm.org/D81583</font></u></a><font size="2"> </font><br><font size="2"><br>the introduction of the C++20 [[no_unique_address]] attribute exposes an ABI issue on platforms that require special handling for structs/classes that are "equivalent" to a single floating-point member (or in some cases, a "homogeneous" set of floating-point members). This is because we can now for the first time have "empty" members in a C++ class, which affects that determination.</font><br><font size="2"><br>The Itanium C++ ABI document was updated to include these new cases, and GCC 10 was changed accordingly. However, current clang/LLVM mainline does not comply with this new ABI. The Phabricator review I posted above fixes that for the SystemZ target, but because I'm touching some amount of common code, and because -to the best of my understanding- other platforms would actually likewise be affected, I'm asking for comments here as well.</font><br><font size="2"><br>Given that we're nearing the time frame to create the LLVM 11 branch, it would really be good if this issue could be fixed before the branch.</font><br><br><font size="2"><br>Bye,<br>Ulrich</font><br><br>_______________________________________________<br>LLVM Developers mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><u><font color="#0000FF">llvm-dev@lists.llvm.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><u><font color="#0000FF">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</font></u></a><tt><font size="2">_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br></font></tt><tt><font size="2"><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></font></tt><tt><font size="2"> <br></font></tt><br><br><br></ul><BR>
</body></html>