[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
From:       Florian Weimer <fw () deneb ! enyo ! de>
Date:       2016-02-07 20:48:40
Message-ID: 87k2mgutzr.fsf () mid ! deneb ! enyo ! de
[Download RAW message or body]

* 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.
[prev in list] [next in list] [prev in thread] [next in thread]