Why does/ does not NRVO kick in g++ in the code below?

Question

I have been looking into NRVO and it's support on different compilers, and came across strange behaviour, which is rather confusing.

The sample code:

    #include <iostream>
    using namespace std;

    class X {
        public:
            X() {
                cout << "Constructor 1" << endl;
            }   
    };

    X test() {
        X a;
        cout << &a << endl;
        return a;
    }

    int main() {
        X b = test();
        cout << &b << endl;
        return 0;
    }

After compilation with optimization level 2(or 3) the output is 2 different memory addresses. Although, as far as I understand the function code is valid for NRVO.

P.S. Same code compiled with VS2010 and optimization level 2 uses NRVO.

If I add additional constructor:

X(const X& h) { 
    cout << "Contsructor 2" << endl;        
}

After compilation addresses are the same, so I assume NRVO was applied, but it happens independent of optimization level.

Does "X(const X& h)" somehow imply to g++ to use NRVO? Or NRVO is not applied at all and it is something different?

Thanks in advance.

Added. GCC version:

$ g++ -v

Configured with: [....] -enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

gcc version 4.4.3

Additional tests: Compiled with X(const X& h) construct and -fno-elide-constructors g++ flag it calls "copy" constructor, expected behaviour. Without it NRVO fails. Tested on different machines: gcc 4.4.3 and gcc 4.3.* -> same results.

So far I am not sure whether __cxa_atexit (present in @yves 's version of g++) somehow influences different behaviour. (As far as I understand it is nothing to do with it, but I don't fully understand the changes it brings into call order)

Which compiler version are you using please? – yves Baumes Feb 10 '12 at 13:45 — yves Baumes, Feb 10 '12 at 13:45

yves Baumes · Answer 1 · 2012-02-13T12:49:23.250

For me it is ok, nrvo applies even though I did not enable optimisation:

$ mk nrvo
g++     nrvo.cpp   -o nrvo
$ ./nrvo
Constructor 1
0xbfe5a520
0xbfe5a520
$ g++ -v
Lecture des spécification à partir de /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Modèle de thread: posix
version gcc 3.4.6 20060404 (Red Hat 3.4.6-8)

EDIT: Try to compile with full optim:

g++ -O3 nrvo.cpp   -o nrvo

Hope it helps.

score 0 · Accepted Answer · answered Dec 21 '14 at 20:16

Whether RVO is possible depends on the ABI. Even if the C++ standard allows it, an implementation's ABI might not. Quoting the Itanium C++ ABI:

In general, C++ return values are handled just like C return values. This includes class type results returned in registers. However, if the return value type has a non-trivial copy constructor or destructor, the caller allocates space for a temporary, and passes a pointer to the temporary as an implicit first parameter preceding both the this parameter and user parameters. The callee constructs the return value into this temporary.

Note: despite the name, the Itanium C++ ABI is not just used on Itanium.

And the referenced base C ABI specifies that structs get returned in a register if they are of specific sizes. This is also the case for the struct (class) in your question. Having a non-trivial copy constructor or destructor makes it impossible to return the class in a register, so the ABI has to specify different rules, and under those different rules, RVO is possible.

Why does/ does not NRVO kick in g++ in the code below?

2 Answers2