Why does/ does not NRVO kick in g++ in the code below?
-
28-04-2021 - |
Pergunta
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)
Solução
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.
Outras dicas
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.