On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith <rich...@metafoo.co.uk>
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith <rich...@metafoo.co.uk>
>>>>> wrote:
>>>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith <rich...@metafoo.co.uk>
>>>>>>> wrote:
>>>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>>>> > <matthijsvand...@gmail.com> wrote:
>>>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>>>> >>> struct A {
>>>>>>>>> >>> static void foo (void) ();
>>>>>>>>> >>> static int xxx;
>>>>>>>>> >>> };
>>>>>>>>> >>
>>>>>>>>> >> What about it? It's an empty struct. (And it declares a function
>>>>>>>>> >> and
>>>>>>>>> >> a variable in the namespace of A, which however do not have any
>>>>>>>>> >> relevant impact here.)
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>> > Thanks for all the feedbacks. Here is the new proposal:
>>>>>>>>> >
>>>>>>>>> > 1. "empty type". An empty type is a trivially-copyable aggregate
>>>>>>>>> > occupying zero bytes (excluding any padding).
>>>>>>>>> > 2. No memory slot nor register should be used to pass or return an
>>>>>>>>> > object
>>>>>>>>> > of empty type.
>>>>>>>>> >
>>>>>>>>> > Footnote: Array of empty type can only passed by reference in C/C++.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> I updated intel386, x86-64 and IA MCU psABIs:
>>>>>>>>>
>>>>>>>>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>>>>>>>>
>>>>>>>>> to specify:
>>>>>>>>>
>>>>>>>>> Empty type is defined as a trivially-copyable aggregate occupying
>>>>>>>>> zero bytes
>>>>>>>>> (excluding any padding).
>>>>>>>>
>>>>>>>> I think this is now extremely unclear. Does an empty struct in C++
>>>>>>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>>>>>>
>>>>>>> Can it be considered as padding?
>>>>>>
>>>>>> Perhaps, but I would contend that that's unclear in at least some
>>>>>> cases (when the class is used as the type of a member, ...). What
>>>>>> about this case:
>>>>>>
>>>>>> struct X { unsigned : 15; };
>>>>>>
>>>>>> Is that empty or not? Do we have a formal definition somewhere of what
>>>>>> does, and does not, count as padding?
>>>>>
>>>>> How about this?
>>>>>
>>>>> Empty type is defined as a trivially-copyable aggregate occupying zero
>>>>> bytes
>>>>> (excluding any padding or contributing zero bytes to the size of derived
>>>>> classes in C++).
>>>>>
>>>>> This will cover
>>>>>
>>>>> struct dummy0
>>>>> {
>>>>> void bar (void);
>>>>> };
>>>>> struct dummy1
>>>>> {
>>>>> void foo (void);
>>>>> };
>>>>> struct dummy : dummy0, dummy1 { };
>>>>>
>>>>> But not
>>>>>
>>>>> struct dummy0
>>>>> {
>>>>> };
>>>>> struct dummy1
>>>>> {
>>>>> unsigned : 15;
>>>>> };
>>>>> struct dummy : dummy0, dummy1
>>>>> {
>>>>> };
>>>>
>>>> Why not? That looks empty to me. The ABI will classify the
>>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>>> should not be passed.
>>>
>>> Do you have a wording to describe it?
>>
>> Yes, something like what you had before was fine:
>>
>> "empty type". An empty type is a type where it and all of its
>> subobjects (recursively) are of class, structure, union, or array
>> type.
>>
>> Or, if you think it makes the intent clearer, reverse the sense:
>>
>> A type is non-empty if it or any subobject (recursively) is of any
>> type other than class, structure, union, or array type.
>
> Does the above cover
>
> struct dummy0
> {
> void bar (void);
> };
> struct dummy1
> {
> void foo (void);
> };
> struct dummy : dummy0, dummy1 { };
Yes
>> If you like, you could add notes that a parameter type is never an
>> array type, and that unnamed bit-fields are not subobjects, but they
>> seem redundant given the wording of the relevant standards. (You don't
>> need to say anything about "POD for the purpose of layout", or
>> destructors, or whatever else, because the C++ ABI only delegates to
>> the C psABI for cases that are valid to pass in registers from a C++
>> language semantics point of view.)
>
>
>
> --
> H.J.
