On Sun, Feb 7, 2016 at 12:08 PM, Florian Weimer <f...@deneb.enyo.de> wrote:
> * H. J. Lu:
>
>>> Any syntactical array argument (at the C level) is should be passed as
>>> a pointer. The language appears to change that.
>>
>> I didn't use aggregate so that array is excluded here.
>>
>>> For 2., static members and non-data members do not count.
>>
>> They do count here. That is why I used "POD for the purpose of
>> layout.
>
> Let's see what happens today.
>
> struct s0 {
> s0();
> };
>
> struct s1 {
> static int a;
> };
>
> struct s2 {
> void member();
> };
>
> struct s3 {
> int a[0];
> };
>
> struct s4 {
> s0 a[0];
> };
>
> struct s5 {
> s1 a[1];
> };
>
>
> 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.
> 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.
--
H.J.
