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 Sat, 20 Feb 2016, H.J. Lu wrote:

On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith <richard@metafoo.co.uk> wrote:
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz <matz@suse.de> wrote:
Hi,

On Thu, 18 Feb 2016, Richard Smith wrote:

An empty type is a type where it and all of its subobjects
(recursively) are of class, structure, union, or array type.  No
memory slot nor register should be used to pass or return an object
of empty type.

The trivially copyable is gone again.  Why is it not necessary?

The C++ ABI doesn't defer to the C psABI for types that aren't
trivially-copyable. See
http://mentorembedded.github.io/cxx-abi/abi.html#normal-call

Hmm, yes, but we don't want to define something for only C and C++, but
language independend (so far as possible).  And given only the above
language I think this type:

struct S {
  S() {something();}
};

would be an empty type, and that's not what we want.

Yes it is. Did you mean to give S a copy constructor, copy assignment
operator, or destructor instead?

"Trivially copyable"
is a reasonably common abstraction (if in doubt we could even define it in
the ABI), and captures the idea that we need well (namely that a bit-copy
is enough).

In this case:

struct dummy0
{
};

struct dummy
{
 dummy0 d[20];

 dummy0 * foo (int i);
};

dummy0 *
dummy::foo (int i)
{
 return &d[i];
}

dummy0 *
bar (dummy d, int i)
{
 return d.foo (i);
}

dummy shouldn't be passed as empty type.

Why not?

We need to have a clear definition for what kinds of member functions are allowed in an empty type.

--
Marc Glisse


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