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

List:       cfe-commits
Subject:    Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
From:       "H.J. Lu via cfe-commits" <cfe-commits () lists ! llvm ! org>
Date:       2016-02-07 20:52:15
Message-ID: CAMe9rOoMujhjExxKWrz-Dv8uE33X=Upvi_X_HZsfeN0GS+=56A () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * 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.

Not really.  For

struct dummy0 { };
struct dummy { struct dummy0 d[PAD_SIZE]; };

clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
on ia32.

>>> 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.

Sure.  Do you care to propose a wording for "POD for the purpose of layout"?


-- 
H.J.
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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