This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mutually-recursive types and an old puzzle
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot COM>, Chris Lattner <sabre at nondot dot org>, gcc at gcc dot gnu dot org
- Date: Thu, 01 Jul 2004 10:41:54 -0700
- Subject: Re: mutually-recursive types and an old puzzle
- References: <Pine.LNX.4.44.0406291930070.1537-100000@nondot.org><32877.::ffff:128.194.146.36.1088556186.squirrel@webmail.nerim.net><20040629175356.A11677@synopsys.com><32929.::ffff:128.194.146.36.1088557164.squirrel@webmail.nerim.net><20040630122238.A23557@synopsys.com><877jtox2ef.fsf@taltos.codesourcery.com><32822.::ffff:24.250.169.187.1088649121.squirrel@webmail.nerim.net><20040701091139.A20201@synopsys.com> <40E44326.30807@codesourcery.com><20040701101911.A25685@synopsys.com> <40E44B17.90004@codesourcery.com>
Nathan Sidwell <nathan@codesourcery.com> writes:
> Joe Buck wrote:
>
>> Then this would not prevent STL iterators from being returned in
>> registers, as they don't have destructors and they don't have non-trivial
>> copy constructors (when not in debug mode). But neither did my FsmState
>> example, and Zack says it can't be returned in a register. So what gives?
>> In both cases, the iterator is generally a one-field object, where the one
>> field is a pointer; the copy constructor is the default one that just
>> copies the fields, and there is no destructor.
> In the FSM example, I'm not sure why Zack says it can't be returned in
> a register. And given what you say about iterators, I don't see
> why they can't be either (modulo underlying CABI restrictions).
Zack was mistaken; it is returned in a register on e.g. powerpc. I
had misremembered the requirements of the C++ ABI. It is *not*
returned in a register on x86 but that is, as Gaby says, down to the
psABI.
zw