[llvm-dev] [RFC] C++20 ABI issue on several platforms

[Jinsong Ji via llvm-dev]

Thanks Hubert.

This simple example may work for ppc64le, but I think we still need to fix
some other issues.
eg: We do use isSingleElementStruct in getParamTypeAlignment as well.


Best,

Jinsong Ji (纪金松), PhD.

XL/LLVM on Power Compiler Development
E-mail: jji at us.ibm.com



From:	Hubert Tong via llvm-dev <llvm-dev at lists.llvm.org>
To:	Ulrich Weigand <Ulrich.Weigand at de.ibm.com>
Cc:	LLVM Developers Mailing List <llvm-dev at lists.llvm.org>, Clang
            Dev <cfe-dev at lists.llvm.org>
Date:	07/07/2020 10:25 AM
Subject:	[EXTERNAL] Re: [llvm-dev] [RFC] C++20 ABI issue on several
            platforms
Sent by:	"llvm-dev" <llvm-dev-bounces at lists.llvm.org>



As information, it seems no_unique_address handling already works for
PPC64LE:
struct A {
  int : 0;
};

struct B {
  float f;
  struct A a [[no_unique_address]];
};

void f(B);

void g(B *bp) {
  f(*bp);
}

Uses:
lfsx 1, 0, 3

Compiler Explorer link: https://godbolt.org/z/tHkSRQ

On Tue, Jul 7, 2020 at 8:25 AM Ulrich Weigand via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
  Hello,

  as discussed here in more detail: https://reviews.llvm.org/D81583

  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.

  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.

  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.


  Bye,
  Ulrich

  _______________________________________________
  LLVM Developers mailing list
  llvm-dev at lists.llvm.org
  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
  _______________________________________________
  LLVM Developers mailing list
  llvm-dev at lists.llvm.org
  https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=DvnnfavFQBGT2CDyHzTr_Q&m=ZxkpwoIX2r0-rd7A8lfvGW_KeOUZq0vUxnwEMX3aVSM&s=JfHfgBqIoPVo_ovA83BQviEkBuMrdXoMESaKoeH61XA&e=



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200707/c6eb9bad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200707/c6eb9bad/attachment.gif>