[Bug c++/58051] New: No named return value optimization when returned object is implicitly converted

[Bug c++/58051] New: No named return value optimization when returned object is implicitly converted

[scovich at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

            Bug ID: 58051
           Summary: No named return value optimization when returned
                    object is implicitly converted
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: scovich at gmail dot com

The following test case introduces an extra object copy, even though none
should be required:

// <<<--- bug.cpp --->>>
extern "C" void puts(char const *);
struct A {
    A()=default;
    A(A &&)=default;
    A(A const &) { puts("copy"); }
    ~A() { puts("~A"); }
};
struct B {
    A _a;
    B(A a) : _a((A&&)(a)) { }
};
B go() {
    A rval;
    return rval;
}
int main () { go(); }
// <<<--- end bug.cpp --->>>

(when compiled with both `gcc-4.8.1 -std=gnu++11' and `gcc-4.6.3 -std=gnu++0x')

RVO works properly if go() returns A() or std::move(rval).

[Bug c++/58051] No named return value optimization when returned object is implicitly converted

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement

[Bug c++/58051] No named return value optimization when returned object is implicitly converted

[piotr5 at netscape dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

piotr5 at netscape dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotr5 at netscape dot net

--- Comment #1 from piotr5 at netscape dot net ---
I have the same problem, it makes the r-value types tedious.
however this is not a bug in gcc directly, it's a bug in stdc++1x specs
omitting this special case and what should be done here. however, as a
feature-request I suggest at least when accepting gcc extensions to the
standard (or better yet check with the stdc++1x paper if this contradicts the
standard), gcc should proceed as suggested in this bug-report.

more concretely: if in the example given the return-value rval would stay alive
after the return (for example it's static), then the current behaviour of gcc
should be kept. if rval would become destroyed because of going out of scope
through the return, then std::move() should implicitly be added by the compiler
alike to syntactic sugar.

alternatively one could write a software which checks all return statements for
classes which can be r-value initialized and outputs a warning whenever the
return statement doesn't come with std::move() around the returned value and
the used variable is going out of scope. this functionality could also be added
to whatever code-checker. but such a solution would only introduce yet another
hassle for the programmer.

to emphasize: the reason why this feature is important is because gcc doesn't
automatically do garbage-collection. if return-statements copy and destroy some
big class frequently, this creates many holes in memory, cluttering free space.
so this kind of optimization is needed for both, speed and size...

[Bug c++/58051] [DR1579] No named return value optimization when returned object is implicitly converted

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-26
            Summary|No named return value       |[DR1579] No named return
                   |optimization when returned  |value optimization when
                   |object is implicitly        |returned object is
                   |converted                   |implicitly converted
     Ever confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ryan Johnson from comment #0)
> RVO works properly if go() returns A() or std::move(rval).

RVO is already working properly, C++11 did not allow the expression in the
return statement to be treated as an rvalue when it is a different type to the
function's return type.

However the standard changed:
http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

[Bug c++/58051] [DR1579] No named return value optimization when returned object is implicitly converted

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I wonder if it's this simple:

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -8618,8 +8618,6 @@ check_return_expr (tree retval, bool *no_warning)
              || TREE_CODE (retval) == PARM_DECL)
          && DECL_CONTEXT (retval) == current_function_decl
          && !TREE_STATIC (retval)
-         && same_type_p ((TYPE_MAIN_VARIANT (TREE_TYPE (retval))),
-                         (TYPE_MAIN_VARIANT (functype)))
          /* This is only interesting for class type.  */
          && CLASS_TYPE_P (functype))
        flags = flags | LOOKUP_PREFER_RVALUE;

[Bug c++/58051] [DR1579] No named return value optimization when returned object is implicitly converted

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.10.0

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
fixed on trunk