This is the mail archive of the 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]

Re: gcc 3.0.1 & C++ ABI issues

>>>>> "Gabriel" == Gabriel Dos Reis <> writes:

> | > BTW, I've always considered a 'proper' RVO to consist of the ability to
> | > turn
> | > 		Obj thingy;
> | > 		return thingy;
> | > into (pseudo C++)
> | > 		Obj &thingy = *_return_value_ptr;
> | > 		return;
> | > This is somewhat stronger that we do right now isn't it?
> | 
> | We do that now, too, as of my recent patch.  We call that the Named Return
> | Value Optimization, or NRVO.  I still need to get it working with inlines,
> | though; several solutions occur to me, and I'm not sure which is The Way.

> Excuse-me for bugging you about this: did you have look at my patch?

Yes, sorry.  I've been thinking about how best to handle this, and have
written several different working patches, none of which I've been entirely
happy with.  :) I'll start another thread about this.

> | >>>>> "Mark" == Mark Mitchell <> writes:
> | 
> | > Correct code is clearly more important.  So, the patch is OK, but you
> | > should XFAIL the testcase, and enter a PR about it.  Since the RVO is
> | > new (on the 3.1 branch) there's no regression here relative to any
> | > released version of GCC.
> | 
> | No, the NRVO is new, but we have optimized 'return Class();' since before I
> | started working on the compiler.  So this is definitely a regression, if a
> | minor one.  Fortunately it won't affect STL, since the iterator tags don't
> | need constructing.

> There are other parts of the library where I use "return class(args)"
> counting the compiler to do the right thing (which it used to).
> I was planning to change them to use the supposed most efficient NRVO, 
> but now given the news I suppose there is no hurry...

Hmm?  If writing "return class (args)" is reasonable for the function in
question, it is no more or less efficient than the NRVO.  The NRVO is most
useful for more complicated functions.

> [...]

> | Are you thinking of this:
> | 
> |   inline A f (A a) { return a; }
> | 
> |   int main ()
> |   {
> |     A a1 = f (A ());
> |   }
> | 
> | ?  Currently, this would involve two constructor calls, the default ctor to
> | construct the parameter and the copy ctor to initialize 'a1'.  It seems
> | reasonable to elide the copy ctor in this case,

> Most people expect that.

> |  but IMO the standard doesn't allow it. 

> Really?  I think it is allowed: 12.8/15

>    Whenever a temporary class object is copied using a copy constructor,
>    and this object and the copy have the same cv-unqualified type, an
>    implementation is permitted to treat the original and the copy as two
>    different ways of referring to the same object and not perform a copy
>    at all, even if the class copy constructor or destructor have side
>    effects.  [...]

The copy constructor I see is for copying the parameter 'a' into the return
value of f.  'a' is not a temporary, it is a parameter, so the passage you
quote doesn't apply.


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