This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>, cfe-commits <cfe-commits at lists dot llvm dot org>
- Date: Sun, 07 Feb 2016 21:48:40 +0100
- Subject: Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOofYT89yzF6jxFZFG2=QVQuQpEC7DP0HV_epjeawCf_sA at mail dot gmail dot com> <87d1s8wc4w dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOp_6ZpR1YSJZ7AiLpa+FPRGJoLm5fTPkiH5BgF4Tkg3RA at mail dot gmail dot com> <87r3gouvv2 dot fsf at mid dot deneb dot enyo dot de> <CAMe9rOo2tPZKZEgpgFbbSnkyBiONzS9vfntn_QsxRPbVHZGmUw at mail dot gmail dot com>
* 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.