On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer <f...@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
