[RFC] C++20 ABI issue on several platforms

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] C++20 ABI issue on several platforms

Keane, Erich via cfe-dev

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


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-dev
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 <[hidden email]> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-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: [hidden email]


Inactive hide details for Hubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handlHubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handling already works for PPC64LE:

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





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 <[hidden email]> 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
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________
    LLVM Developers mailing list
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 




_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-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/


Inactive hide details for Jinsong Ji---07.07.2020 17:03:10---Thanks Hubert.  This simple example may work for ppc64le, but I thJinsong 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

From: Jinsong Ji/Jacksonville/IBM
To: Hubert Tong <[hidden email]>
Cc: Clang Dev <[hidden email]>, LLVM Developers Mailing List <[hidden email]>, "llvm-dev" <[hidden email]>, Ulrich Weigand <[hidden email]>
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: [hidden email]



Inactive hide details for Hubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handlHubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handling already works for PPC64LE:

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




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 <[hidden email]> 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
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________
    LLVM Developers mailing list
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 





_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-dev

Thanks Ulrich! We will have a look for ppc64le.

Best,

Jinsong Ji (纪金松), PhD.

XL/LLVM on Power Compiler Development
E-mail: [hidden email]


Inactive hide details for Ulrich Weigand---07/07/2020 11:27:31 AM---Hi Jinsong, yes, exactly.  I was just trying a more complicUlrich Weigand---07/07/2020 11:27:31 AM---Hi Jinsong, yes, exactly. I was just trying a more complicated case:

From: Ulrich Weigand/Germany/IBM
To: Jinsong Ji/Jacksonville/IBM@IBMUS
Cc: Hubert Tong <[hidden email]>, Clang Dev <[hidden email]>, LLVM Developers Mailing List <[hidden email]>
Date: 07/07/2020 11:27 AM
Subject: Re: [llvm-dev] [RFC] C++20 ABI issue on several platforms




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/


Inactive hide details for Jinsong Ji---07.07.2020 17:03:10---Thanks Hubert.  This simple example may work for ppc64le, but I thJinsong 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

From: Jinsong Ji/Jacksonville/IBM
To: Hubert Tong <[hidden email]>
Cc: Clang Dev <[hidden email]>, LLVM Developers Mailing List <[hidden email]>, "llvm-dev" <[hidden email]>, Ulrich Weigand <[hidden email]>
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: [hidden email]



Inactive hide details for Hubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handlHubert Tong via llvm-dev ---07/07/2020 10:25:24 AM---As information, it seems no_unique_address handling already works for PPC64LE:

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




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 <[hidden email]> 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
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev_______________________________________________
    LLVM Developers mailing list
    [hidden email]
    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 






_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-dev
In reply to this post by Keane, Erich via cfe-dev
On Tue, Jul 7, 2020 at 2:25 PM Ulrich Weigand via llvm-dev
<[hidden email]> 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.

Hi Ulrich,

I see that the patch linked above landed before the branch date. Do I
understand that there's nothing more that needs to be done here for
LLVM 11?

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Keane, Erich via cfe-dev

Hans Wennborg <[hidden email]> wrote on 27.07.2020 16:58:57:

> Hi Ulrich,
>
> I see that the patch linked above landed before the branch date. Do I
> understand that there's nothing more that needs to be done here for
> LLVM 11?

Hi Hans,

yes, this has all been merged, so there's nothing more to do be done.

Thanks,
Ulrich


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev