RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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