RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
Florian Weimer via cfe-commits
cfe-commits at lists.llvm.org
Sun Feb 7 12:48:40 PST 2016
* H. J. Lu:
>> I tested GCC 5.3.1 and Clang 3.5.0.
>>
>> GCC Clang
>> s0 non-empty non-empty
>> s1 non-empty empty
>> s2 non-empty empty
>> s3 empty empty
>> s4 empty empty
>> s5 non-empty empty
>>
>> I believe s3, s4, s5 are non-empty according to your rules. Why put
>> both compilers in the wrong? That doesn't make sense to me.
>
> Please try testcases in
>
> https://llvm.org/bugs/show_bug.cgi?id=26337
>
> with clang on both ia32 and x86-64. Clang isn't consistent between
> ia32 and x86-64.
Okay, with -m32, I get non-empty passing for s5 from Clang as well.
But I still don't think it makes sense to change the ABI for s3 and
s4, and even for s5, the Clang/x86_64 behavior is arguably more
correct.
>> Jason already indicated he intends GCC to move towards more empty
>> arguments, not fewer.
>>
>>>> How do existing C++ compilers implement empty array members (an
>>>> extension)? Does the type of such members affect whether a class is a
>>>> standard-layout class?
>>
>>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>>
>> The C++ standard does not define this.
>
> GCC has
>
> * Nonzero means that this class type is not POD for the purpose of layout
> (as defined in the ABI). This is different from the language's POD. */
> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>
> We can use this definition for ia32, x86-64 and IA MCU psABIs.
It still has to be spelled out in non-GCC terms, IMHO.
More information about the cfe-commits
mailing list