[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat abandoned this revision.
wangleiat added a comment.

We have decided to keep it unchanged. Thank you, everyone.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

As far as I'm concerned as editor of the Itanium ABI, the ABI treatment of 
trivial-for-the-purposes-of-calls classes is purely a psABI matter, and the 
Itanium ABI's wording around empty classes is merely a suggestion if the psABI 
doesn't have more specific rules (because empty structs are normally invalid in 
C).  Do what you think is best for your ABI.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

If you are really determined to do this, then OK.  I'm in a very bad
mood and I don't want to spend my mental strength on debating (esp. on a
corner case unlikely to affect "real" code) anymore.

But remember to add a entry in GCC 14 changes.html, and test this thing:

struct Empty {};

struct Something : Empty
{

  double a, b;

};

If we are not careful enough we may introduce a ABI mismatch between -
std=c++14 and -std=c++17 here.  See https://gcc.gnu.org/PR94383.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: efriedma, rjmccall.
aaron.ballman added a comment.

Adding codegen code owners as reviewers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[WÁNG Xuěruì via Phabricator via cfe-commits]

xen0n added a comment.

FYI, in the matching GCC patch discussion 
 it was 
suggested that such a treatment wouldn't be necessary in principle.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

In D151298#4367620 , @wangleiat wrote:

 If we want to ignore empty structures, it is not enough to only modify 
 psABI, because the current implementations of gcc and clang do not ignore 
 empty structures in all cases. For example:

   struct { struct{}; int i; }; // in this case, the empty struct is not 
 ignored.
   struct { struct{}; float f; }; // ignored.
>>>
>>> This is the same behavior as RISC-V.  While attempting to pass a struct 
>>> through FPRs, the empty field is ignored.  But if passing through FPR does 
>>> not work and it's passed through GPRs, the empty fields are not ignored:
>
> Yes, but our psABI still differs from RISC-V in the description of parameter 
> passing, and it would be better to have consistent behavior regardless of 
> whether there are floating points or not.

But it's easier to just modify the text of the ABI doc, in order to avoid an 
ABI incompatibility between different GCC of Clang versions (as GCC and Clang 
are only C++ compilers supporting LoongArch now).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat added a comment.

>>> If we want to ignore empty structures, it is not enough to only modify 
>>> psABI, because the current implementations of gcc and clang do not ignore 
>>> empty structures in all cases. For example:
>>>
>>>   struct { struct{}; int i; }; // in this case, the empty struct is not 
>>> ignored.
>>>   struct { struct{}; float f; }; // ignored.
>>
>> This is the same behavior as RISC-V.  While attempting to pass a struct 
>> through FPRs, the empty field is ignored.  But if passing through FPR does 
>> not work and it's passed through GPRs, the empty fields are not ignored:

Yes, but our psABI still differs from RISC-V in the description of parameter 
passing, and it would be better to have consistent behavior regardless of 
whether there are floating points or not.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

In D151298#4367496 , @xry111 wrote:

> In D151298#4367458 , @wangleiat 
> wrote:
>
>>> I think the paragraph means:
>>>
>>>   class Empty {};
>>>   int test(Empty empty, int a);
>>>
>>> Then we should put `a` into `a1`, not `a0`.  And we are indeed doing so.
>>
>> yes. with this patch, `a` will be passed with `a1` register.
>>
>>> I mean now GCC and Clang have the same behavior, so it's easier to just 
>>> document the behavior in our psABI doc instead of making both Clang and GCC 
>>> rigidly following the interpretation of psABI (which is currently unclear 
>>> about zero-sized fields now) anyway.
>>>
>>> And the current behavior of GCC and Clang treating a class containing two 
>>> floating-point members and some empty fields is same as RISC-V, so it's 
>>> highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the 
>>> entire RISC-V ecosystem would be violating them).  The only issue is our 
>>> psABI is unclear about empty fields, and the easiest way to solve the issue 
>>> is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V 
>>> psABI if there is no copyright issue).
>>
>> If we want to ignore empty structures, it is not enough to only modify 
>> psABI, because the current implementations of gcc and clang do not ignore 
>> empty structures in all cases. For example:
>>
>>   struct { struct{}; int i; }; // in this case, the empty struct is not 
>> ignored.
>>   struct { struct{}; float f; }; // ignored.
>
> This is the same behavior as RISC-V.  While attempting to pass a struct 
> through FPRs, the empty field is ignored.  But if passing through FPR does 
> not work and it's passed through GPRs, the empty fields are not ignored:
>
> https://godbolt.org/z/T1PKoxbYM
>
>> Whether to ignore empty structures or not can affect the testing of gdb. 
>> @seehearfeel knows more details.
>
> I guess we should be able to fix it for GDB because they must have fixed it 
> for RISC-V already.

@seahearfeel: 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f0272f8548164b024ff9fd151686b2b904a5d59


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

In D151298#4367458 , @wangleiat wrote:

>> I think the paragraph means:
>>
>>   class Empty {};
>>   int test(Empty empty, int a);
>>
>> Then we should put `a` into `a1`, not `a0`.  And we are indeed doing so.
>
> yes. with this patch, `a` will be passed with `a1` register.
>
>> I mean now GCC and Clang have the same behavior, so it's easier to just 
>> document the behavior in our psABI doc instead of making both Clang and GCC 
>> rigidly following the interpretation of psABI (which is currently unclear 
>> about zero-sized fields now) anyway.
>>
>> And the current behavior of GCC and Clang treating a class containing two 
>> floating-point members and some empty fields is same as RISC-V, so it's 
>> highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the 
>> entire RISC-V ecosystem would be violating them).  The only issue is our 
>> psABI is unclear about empty fields, and the easiest way to solve the issue 
>> is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V 
>> psABI if there is no copyright issue).
>
> If we want to ignore empty structures, it is not enough to only modify psABI, 
> because the current implementations of gcc and clang do not ignore empty 
> structures in all cases. For example:
>
>   struct { struct{}; int i; }; // in this case, the empty struct is not 
> ignored.
>   struct { struct{}; float f; }; // ignored.

This is the same behavior as RISC-V.  While attempting to pass a struct through 
FPRs, the empty field is ignored.  But if passing through FPR does not work and 
it's passed through GPRs, the empty fields are not ignored:

https://godbolt.org/z/T1PKoxbYM

> Whether to ignore empty structures or not can affect the testing of gdb. 
> @seehearfeel knows more details.

I guess we should be able to fix it for GDB because they must have fixed it for 
RISC-V already.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat added a comment.

> I think the paragraph means:
>
>   class Empty {};
>   int test(Empty empty, int a);
>
> Then we should put `a` into `a1`, not `a0`.  And we are indeed doing so.

yes. with this patch, `a` will be passed with `a1` register.

> I mean now GCC and Clang have the same behavior, so it's easier to just 
> document the behavior in our psABI doc instead of making both Clang and GCC 
> rigidly following the interpretation of psABI (which is currently unclear 
> about zero-sized fields now) anyway.
>
> And the current behavior of GCC and Clang treating a class containing two 
> floating-point members and some empty fields is same as RISC-V, so it's 
> highly unlikely we are violating the C++ standard or IA64 C++ ABI (or the 
> entire RISC-V ecosystem would be violating them).  The only issue is our 
> psABI is unclear about empty fields, and the easiest way to solve the issue 
> is revising the psABI (maybe, just "borrowing" some paragraphs from RISC-V 
> psABI if there is no copyright issue).

If we want to ignore empty structures, it is not enough to only modify psABI, 
because the current implementations of gcc and clang do not ignore empty 
structures in all cases. For example:

  struct { struct{}; int i; }; // in this case, the empty struct is not ignored.
  struct { struct{}; float f; }; // ignored.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

In D151298#4367349 , @wangleiat wrote:

> In D151298#4367225 , @xry111 wrote:
>
>> In D151298#4367215 , @wangleiat 
>> wrote:
>>
>>> In D151298#4367163 , @xry111 
>>> wrote:
>>>
 Blocking this as it's a deliberate decision made in D132285 
 .

 Is there any imperative reason we must really pass the empty struct?  The 
 C++ standard only treats struct {} as size 1 for the semantics of pointer 
 comparison.  While there is no pointers to registers, ignoring it in the 
 register calling convention will make no harm.

 And AFAIK it will be an undefined behavior attempting to (mis)use the 
 padding space of/after the empty struct to pass any information.
>>>
>>> Our current modifications are closer to the description of `Itanium C++ 
>>> ABI`, and we try to keep it consistent with the description of the calling 
>>> convention under `reasonable premise`.
>>
>> Hmm, could you provide a link to the section saying this in the Itanium C++ 
>> ABI?
>
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#empty-parameters
> http://itanium-cxx-abi.github.io/cxx-abi/abi.html#emptty-return-values
>
>> I see it has some words about passing or returning an empty class, but there 
>> seems no words about passing a class containing an empty class.
>
> It's possible that my understanding is incorrect. There is indeed no place to 
> see how an empty class is passed, just like there is no documentation on how 
> to pass `class A { class B { char c;};};`.

I think the paragraph means:

  class Empty {};
  int test(Empty empty, int a);

Then we should put `a` into `a1`, not `a0`.  And we are indeed doing so.

>> And for our own psABI, it's easier to simply reword it (making it similar to 
>> the RISC-V psABI about passing args with FPRs) instead of modifying both 
>> Clang and GCC (causing the code of Clang and GCC more nasty, and both 
>> compilers slower, and we'll need to add a -Wpsabi warning at least in GCC 
>> too).  And it already needs a reword considering empty arrays and zero-width 
>> bit-fields anyway.
>
> I'm sorry, I couldn't quite understand what you meant.

I mean now GCC and Clang have the same behavior, so it's easier to just 
document the behavior in our psABI doc instead of making both Clang and GCC 
rigidly following the interpretation of psABI (which is currently unclear about 
zero-sized fields now) anyway.

And the current behavior of GCC and Clang treating a class containing two 
floating-point members and some empty fields is same as RISC-V, so it's highly 
unlikely we are violating the C++ standard or IA64 C++ ABI (or the entire 
RISC-V ecosystem would be violating them).  The only issue is our psABI is 
unclear about empty fields, and the easiest way to solve the issue is revising 
the psABI (maybe, just "borrowing" some paragraphs from RISC-V psABI if there 
is no copyright issue).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat added a comment.

In D151298#4367225 , @xry111 wrote:

> In D151298#4367215 , @wangleiat 
> wrote:
>
>> In D151298#4367163 , @xry111 wrote:
>>
>>> Blocking this as it's a deliberate decision made in D132285 
>>> .
>>>
>>> Is there any imperative reason we must really pass the empty struct?  The 
>>> C++ standard only treats struct {} as size 1 for the semantics of pointer 
>>> comparison.  While there is no pointers to registers, ignoring it in the 
>>> register calling convention will make no harm.
>>>
>>> And AFAIK it will be an undefined behavior attempting to (mis)use the 
>>> padding space of/after the empty struct to pass any information.
>>
>> Our current modifications are closer to the description of `Itanium C++ 
>> ABI`, and we try to keep it consistent with the description of the calling 
>> convention under `reasonable premise`.
>
> Hmm, could you provide a link to the section saying this in the Itanium C++ 
> ABI?

http://itanium-cxx-abi.github.io/cxx-abi/abi.html#empty-parameters
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#emptty-return-values

> I see it has some words about passing or returning an empty class, but there 
> seems no words about passing a class containing an empty class.

It's possible that my understanding is incorrect. There is indeed no place to 
see how an empty class is passed, just like there is no documentation on how to 
pass `class A { class B { char c;};};`.

> And for our own psABI, it's easier to simply reword it (making it similar to 
> the RISC-V psABI about passing args with FPRs) instead of modifying both 
> Clang and GCC (causing the code of Clang and GCC more nasty, and both 
> compilers slower, and we'll need to add a -Wpsabi warning at least in GCC 
> too).  And it already needs a reword considering empty arrays and zero-width 
> bit-fields anyway.

I'm sorry, I couldn't quite understand what you meant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

In D151298#4367215 , @wangleiat wrote:

> In D151298#4367163 , @xry111 wrote:
>
>> Blocking this as it's a deliberate decision made in D132285 
>> .
>>
>> Is there any imperative reason we must really pass the empty struct?  The 
>> C++ standard only treats struct {} as size 1 for the semantics of pointer 
>> comparison.  While there is no pointers to registers, ignoring it in the 
>> register calling convention will make no harm.
>>
>> And AFAIK it will be an undefined behavior attempting to (mis)use the 
>> padding space of/after the empty struct to pass any information.
>
> Our current modifications are closer to the description of `Itanium C++ ABI`, 
> and we try to keep it consistent with the description of the calling 
> convention under `reasonable premise`.

Hmm, could you provide a link to the section saying this in the Itanium C++ ABI?

I see it has some words about passing or returning an empty class, but there 
seems no words about passing a class containing an empty class.

And for our own psABI, it's easier to simply reword it (making it similar to 
the RISC-V psABI about passing args with FPRs) instead of modifying both Clang 
and GCC (causing the code of Clang and GCC more nasty, and both compilers 
slower, and we'll need to add a -Wpsabi warning at least in GCC too).  And it 
already needs a reword considering empty arrays and zero-width bit-fields 
anyway.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat added a comment.

In D151298#4367163 , @xry111 wrote:

> Blocking this as it's a deliberate decision made in D132285 
> .
>
> Is there any imperative reason we must really pass the empty struct?  The C++ 
> standard only treats struct {} as size 1 for the semantics of pointer 
> comparison.  While there is no pointers to registers, ignoring it in the 
> register calling convention will make no harm.
>
> And AFAIK it will be an undefined behavior attempting to (mis)use the padding 
> space of/after the empty struct to pass any information.



In D151298#4367163 , @xry111 wrote:

> Blocking this as it's a deliberate decision made in D132285 
> .
>
> Is there any imperative reason we must really pass the empty struct?  The C++ 
> standard only treats struct {} as size 1 for the semantics of pointer 
> comparison.  While there is no pointers to registers, ignoring it in the 
> register calling convention will make no harm.
>
> And AFAIK it will be an undefined behavior attempting to (mis)use the padding 
> space of/after the empty struct to pass any information.

Our current modifications are closer to the description of `Itanium C++ ABI`, 
and we try to keep it consistent with the description of the calling convention 
under `reasonable premise`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 added a comment.

Note that we are using the "de-facto" ABI throwing away this empty struct since 
the first release of GCC supporting LoongArch, and also Clang.  So is there an 
imperative reason we must change it?

And IIUC we've agreed to revise the ABI since Apr 2022 for this, but 
unfortunately I've never got enough English skill to do the revision myself :(.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[Xi Ruoyao via Phabricator via cfe-commits]

xry111 requested changes to this revision.
xry111 added a comment.
This revision now requires changes to proceed.

Blocking this as it's a deliberate decision made in D132285 
.

Is there any imperative reason we must really pass the empty struct?  The C++ 
standard only treats struct {} as size 1 for the semantics of pointer 
comparison.  While there is no pointers to registers, ignoring it in the 
register calling convention will make no harm.

And AFAIK it will be an undefined behavior attempting to (mis)use the padding 
space of/after the empty struct to pass any information.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D151298/new/

https://reviews.llvm.org/D151298

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D151298: [clang][LoongArch] Fix the calling convention for empty struct in C++ mode

[wanglei via Phabricator via cfe-commits]

wangleiat created this revision.
wangleiat added reviewers: SixWeining, xen0n, xry111, gonglingqin.
Herald added a project: All.
wangleiat requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Prior to this patch, paramter or return value whose type was a
structure containing empty structure members and fewer than three
floating-point members did not meet the calling convention.

With this patch, an empty struct will always be passed.

An empty struct type that is not non-trivial for the purposes of calls
will be treated as though it were the following C type:

  struct {
char c;
  };

Change-Id: If5c7f499d38d1853261dc1dae6620b8fc9db7fd3


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D151298

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCXX/LoongArch/abi-lp64d-empty-struct.cpp

Index: clang/test/CodeGenCXX/LoongArch/abi-lp64d-empty-struct.cpp
===
--- clang/test/CodeGenCXX/LoongArch/abi-lp64d-empty-struct.cpp
+++ clang/test/CodeGenCXX/LoongArch/abi-lp64d-empty-struct.cpp
@@ -6,14 +6,13 @@
 /// If the empty struct is a struct's member, will be treated as
 /// fixed-point member.
 /// WOA: Bit width of the argument.
-/// FIXME: Empty struct is always passed or returned in C++ mode.
 
 /// 1. 0 < WOA <= GRLEN
 /// 1.a. Only fixed-point members.
 
 struct empty_s {};
-// CHECK-LABEL: define dso_local void @_Z12empty_struct7empty_s
-// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local i64 @_Z12empty_struct7empty_s
+// CHECK-SAME: (i64 [[E_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_s empty_struct(struct empty_s e) {
   return e;
 }
@@ -39,8 +38,8 @@
   char c;
   float f32;
 };
-// CHECK-LABEL: define dso_local { i8, float } @_Z23empty_char_float_struct18empty_char_float_s
-// CHECK-SAME: (i8 [[TMP0:%.*]], float [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local i64 @_Z23empty_char_float_struct18empty_char_float_s
+// CHECK-SAME: (i64 [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_char_float_s empty_char_float_struct(struct empty_char_float_s s) {
   return s;
 }
@@ -51,8 +50,8 @@
   struct empty_s e;
   float f32;
 };
-// CHECK-LABEL: define dso_local float @_Z18empty_float_struct13empty_float_s
-// CHECK-SAME: (float [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { i8, float } @_Z18empty_float_struct13empty_float_s
+// CHECK-SAME: (i8 [[TMP0:%.*]], float [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_s empty_float_struct(struct empty_float_s s) {
   return s;
 }
@@ -62,8 +61,8 @@
   struct empty_s e;
 };
 
-// CHECK-LABEL: define dso_local float @_Z18float_empty_struct13float_empty_s
-// CHECK-SAME: (float [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { float, i8 } @_Z18float_empty_struct13float_empty_s
+// CHECK-SAME: (float [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct float_empty_s float_empty_struct(struct float_empty_s s) {
   return s;
 }
@@ -92,8 +91,8 @@
   struct empty_s e;
   double f64;
 };
-// CHECK-LABEL: define dso_local double @_Z19empty_double_struct14empty_double_s
-// CHECK-SAME: (double [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { i8, double } @_Z19empty_double_struct14empty_double_s
+// CHECK-SAME: (i8 [[TMP0:%.*]], double [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_double_s empty_double_struct(struct empty_double_s s) {
   return s;
 }
@@ -102,8 +101,8 @@
   double f64;
   struct empty_s e;
 };
-// CHECK-LABEL: define dso_local double @_Z19double_empty_struct14double_empty_s
-// CHECK-SAME: (double [[TMP0:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local { double, i8 } @_Z19double_empty_struct14double_empty_s
+// CHECK-SAME: (double [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
 struct double_empty_s double_empty_struct(struct double_empty_s s) {
   return s;
 }
@@ -115,8 +114,8 @@
   float f32;
   char c;
 };
-// CHECK-LABEL: define dso_local { float, i8 } @_Z23empty_float_char_struct18empty_float_char_s
-// CHECK-SAME: (float [[TMP0:%.*]], i8 [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local [2 x i64] @_Z23empty_float_char_struct18empty_float_char_s
+// CHECK-SAME: ([2 x i64] [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_char_s empty_float_char_struct(struct empty_float_char_s s) {
   return s;
 }
@@ -126,8 +125,8 @@
   float f32;
   double f64;
 };
-// CHECK-LABEL: define dso_local { float, double } @_Z25empty_float_double_struct20empty_float_double_s
-// CHECK-SAME: (float [[TMP0:%.*]], double [[TMP1:%.*]]) #[[ATTR0:[0-9]+]] {
+// CHECK-LABEL: define dso_local [2 x i64] @_Z25empty_float_double_struct20empty_float_double_s
+// CHECK-SAME: ([2 x i64] [[S_COERCE:%.*]]) #[[ATTR0:[0-9]+]] {
 struct empty_float_double_s empty_float_double_struct(struct empty_float_double_s s) {
   return s;
 }
@@ -150,8 +149,8 @@
   double f64;