This change shouldn't cause many porting headaches, but it did cause one package to fail to build (due to a bug in the package), so it's worth documenting.
Committed to CVS.
Index: porting_to.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/porting_to.html,v retrieving revision 1.5 diff -u -r1.5 porting_to.html --- porting_to.html 18 Feb 2015 13:41:12 -0000 1.5 +++ porting_to.html 10 Mar 2015 17:37:15 -0000 @@ -385,6 +385,38 @@ It is recommended to use <code>true</code>, resp. <code>false</code> keywords in such cases. +<h3>Return by converting move constructor</h3> + +<p>GCC 5 implements +<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579";>DR 1579</a> +which means that in a function like:</p> + +<pre><code> + X + foo() + { + Y y; + return y; + } +</code></pre> + +<p>GCC will first attempt to construct the return value as if <code>y</code> +were an rvalue, and if that fails then it will try again for an lvalue +(all C++11 compilers already do this when returning a variable of the +same type as the function returns, but now they are required to do it +when the types are not the same). +This will change the constructor that gets called in some cases, +for example it might now call <code>X(Y&&)</code> instead of +<code>X(const Y&)</code>. +</p> +<p> +In most cases the only observable difference will be code that runs faster +(by moving instead of copying) but if it causes a problem the new behavior +can be prevented by ensuring the compiler treats <code>y</code> as an lvalue, +using <code>return X(y);</code> or +<code>return static_cast<Y&>(y);</code>. +</p> + <h3>Links</h3> <p>
