This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Smith <richard at metafoo dot co dot uk>
- Cc: Matthijs van Duin <matthijsvanduin at gmail dot com>, Michael Matz <matz at suse dot de>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, cfe-commits <cfe-commits at lists dot llvm dot org>
- Date: Tue, 16 Feb 2016 13:48:28 -0800
- Subject: Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOrsV-zohnj=31_DDYSxUDyRDYL0anTi_NJm5vqogF9URQ at mail dot gmail dot com> <CAMe9rOq5QL9J0F-isO1njJyDJcZ08gF4zUk4vXNONWSfUtSzwA at mail dot gmail dot com> <CAH6eHdR0vJkYuYeKU=zyhthOY0KT-m8C=m2AtZ5GfVeyPOA=jw at mail dot gmail dot com> <CAOfiQqmKnONCdEi=coKaAKO_0Ux5X1BdYZ5t98gCU+LN21xKvw at mail dot gmail dot com> <CAH6eHdTxMXA7BEEHB7y6c5dRG_Hur5=CmdrQWMRn3zRGHnGZuA at mail dot gmail dot com> <CAMe9rOr9CCDjVVdYq7SoCDewg6uLnegEvT3Rrf2jg05SSyM_GQ at mail dot gmail dot com> <CAOfiQqnK-MFNhjcnHPPBpFfcJxR5rkdj26x8HcfMOiibCtevXA at mail dot gmail dot com> <CAMe9rOpM5Cs4zthCTAyaBEx3TWAQ7QNKv=k9mrqNzvj-upGcUw at mail dot gmail dot com> <20160211104729 dot GA3522 at squirrel dot local> <CAMe9rOrVQ2RJJVwKio_yxjGaj8RXcu5oS6K55EWQ0K5xHPtn_Q at mail dot gmail dot com> <CAALWOA_9JdscgL+_1R4RToSOKdwEmS2+P5fctF4RDayjZUS4GA at mail dot gmail dot com> <CAH6eHdQteUNnyPXmuGmwNDgoheotDvJcEM1=qni6-VdEOySUQQ at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602111527090 dot 20277 at wotan dot suse dot de> <CAMe9rOpkV9jdNGfifLOg-uUqGbXwynBiYJTTh2hPcpq+TO3mNg at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602111547280 dot 20277 at wotan dot suse dot de> <CAMe9rOq0SoxOh=WtXJ_VE7CBioRARqub9G59SM+WhbL_VWcaRA at mail dot gmail dot com> <CAALWOA8-NCP+dTf35+PqcemzpPPR+7-Odvt+hUVTTsCmCbhWaQ at mail dot gmail dot com> <CAMe9rOpsgqN5XOSdCbTtwoRz+KbaZxr0s0OMBhRG4Yg=ayT=-Q at mail dot gmail dot com> <CAMe9rOqQLZgEfMBDudAekW_DUDJbofx+bj-O753Brk4YrREa+w at mail dot gmail dot com> <CAOfiQqnyde8eJPsNi=WhmGexZawD9efzeRKX7xgCN39D39BZtg at mail dot gmail dot com> <CAMe9rOoZa7se3JGFy-LMfQETWYHKUXg_jpvcgGfxNvPw+23Byg at mail dot gmail dot com> <CAOfiQqnwP=7Kitkmjm_Vs-FqrD+ro6rOb=NjVBey3h-xJE+7ww at mail dot gmail dot com> <CAMe9rOr4rr1SRVXnkGoZD0Jf46w0TuQKiAVgHRg9nCd0PkV0hA at mail dot gmail dot com> <CAOfiQqmk-h6X1iC+jz70UCyGOAaXJ6f1nuEK64R9Zqir7B=WOA at mail dot gmail dot com> <CAMe9rOqfoW1hqF=nDKbDb3hPEmhb_3U4KMu8HKqoAmdt6_ofJA at mail dot gmail dot com> <CAOfiQq=MJXKNvWYkFsiO07J2Ovf5L-XPv9mNiV-1rY3uQEQFng at mail dot gmail dot com>
On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> 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.
Does the above cover
struct dummy0
{
void bar (void);
};
struct dummy1
{
void foo (void);
};
struct dummy : dummy0, dummy1 { };
> 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.
- References:
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
- Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct