[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:       Florian Weimer via cfe-commits <cfe-commits () lists ! llvm ! org>
Date:       2016-02-07 20:08:17
Message-ID: 87r3gouvv2.fsf () mid ! deneb ! enyo ! de
[Download RAW message or body]

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

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