gcc 3.0.1 & C++ ABI issues

[Gabriel Dos_Reis]

| > 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?
I know it is a year old may be difficult to retrofit in current source.

| >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> 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...

[...]

| 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.  [...]


| We tried to come up with wording to allow that
| optimization, but eventually gave up and just explicitly blessed the NRVO.

I think you did succeed :-)  Both optimizations are allowed.

-- Gaby