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

[Ulrich Weigand via llvm-dev]

Hi Jinsong,

yes, exactly.  I was just trying a more complicated case:

struct A {
  int : 0;
};

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

struct C : B {
  float f;
};

void f(C);

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

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


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  Distinguished Engineer, Open source compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vors. des Aufsichtsrats: Gregor Pillen | Geschäftsführung: Dirk Wittkopp
  Sitz d. Ges.: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB
243294
  Data Privacy Statement der IBM: https://www.ibm.com/privacy/us/en/



From:	Jinsong Ji/Jacksonville/IBM
To:	Hubert Tong <hubert.reinterpretcast at gmail.com>
Cc:	Clang Dev <cfe-dev at lists.llvm.org>, LLVM Developers Mailing
            List <llvm-dev at lists.llvm.org>, "llvm-dev"
            <llvm-dev-bounces at lists.llvm.org>, Ulrich Weigand
            <Ulrich.Weigand at de.ibm.com>
Date:	07.07.2020 17:03
Subject:	Re: [EXTERNAL] Re: [llvm-dev] [RFC] C++20 ABI issue on several
            platforms


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/c0279a49/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/c0279a49/attachment.gif>