This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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"?
>

The standard-layout POD is well defined:

https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data

Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:

1. "collection".  A collection is a structure, union or C++ class.
2. "empty collection".  An empty collection is:
   a. A collection without member.  Or
   b. A collection with only empty collections.  Or
   c. An array of empty collections.
3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
   of standard-layout and
   a. A collection without member.  Or
   b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty record.



-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]