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 Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>>>>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>
>>>>>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>>>>>> > <matthijsvanduin@gmail.com> wrote:
>>>>>>> >> On 11 February 2016 at 16:31, H.J. Lu <hjl.tools@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.

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


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