This is the mail archive of the gcc-patches@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: C++ PATCH to adjust empty class parameter passing ABI


On Thu, Apr 14, 2016 at 11:25:07AM +0100, Ramana Radhakrishnan wrote:
> > I see the test failing on aarch64-none-linux-gnu (native)
> > with no output, just:
> > spawn [open ...]
> > FAIL: g++.dg/abi/empty13.C  -std=gnu++98 execution test
> >
> > And I see it passing on aarch64-none-elf.
> 
> IIRC on AArch64 we document that empty classes and structs take up a
> slot as per the PCS .
> 
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0059b/IHI0059B_cppabi64.pdf
> 
> See section 3.1
> 
> For the purposes of parameter passing in
> [
> AAPCS64
> ], a parameter whose type is an empty class shall be treated as if its
> type were an aggregate with a
> single
> member of type unsigned byte.

One thing is passing such arguments in registers, another is how they are
passed on the stack (e.g. if there are several other arguments that are
passed in registers).
Also, note that the (new) definition of C++ empty class I believe includes
even empty classes that are normally very large, i.e. don't pretend they
are just single byte, but can be e.g. 1024 bytes or longer.
Do you want to still pass them in registers and/or on the stack as if
it is 1 byte, 0 bytes or more bytes?
How do you pass empty C structures?

E.g. looking at sparc-solaris2.12 cross, C for empty structures passes
both in registers and on the stack as if there is one argument (and C++ did
too for the empty classes that pretended to have size 1), so appart from the
ICE in emit_move_insn there is no ABI change, only perhaps for the larger
structs.

Guess we need to figure out what do the various targets do for C empty
structures and decide what we do want to do with C++ empty classes.
Perhaps the C++ FE should just set some flag on the empty class parameters,
and let the backends decide what to do with those?

	Jakub


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