[Bug c++/53637] New: NRVO not applied in branches when it could be

[Bug c++/53637] New: NRVO not applied in branches when it could be

[kenton at google dot com]

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

             Bug #: 53637
           Summary: NRVO not applied in branches when it could be
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kenton@google.com


In the example below it should be possible to apply NRVO.  This situation is
similar to, but more complicated than, the one reported in PR51571.

Note that while this is "just a missed optimization", NRVO can affect the way
interfaces are designed, so aggressively covering all possible cases seems more
important than with most optimizations.

$ cat nrvo.cc 
class Foo {
public:
  Foo() {}

  // Declare but don't define so that if NRVO doesn't kick in we
  // get a linker error.
  Foo(const Foo& other);
};

Foo bar(int i) {
  if (i > 1) {
    Foo result;
    return result;
  } else {
    Foo result;
    return result;
  }
}

int main(int argc, char* argv[]) {
  Foo f = bar(argc);
}

$ g++-4.7 -O2 nrvo.cc
/tmp/ccRlHce1.o: In function `bar(int)':
nrvo.cc:(.text+0xe): undefined reference to `Foo::Foo(Foo const&)'
collect2: error: ld returned 1 exit status
$ g++-4.7 --version
g++-4.7 (Ubuntu/Linaro 4.7.0-7ubuntu3) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/53637] NRVO not applied in branches when it could be

[marc at kdab dot com]

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

marc at kdab dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc at kdab dot com

--- Comment #1 from marc at kdab dot com ---
Similar situation in
https://codereview.qt-project.org/#/c/104079/1/src/network/ssl/qsslellipticcurve_openssl.cpp,unified
(click on the comment in line 61 to see GCC 4.9.3 (from svn) disassembly.

Qt is full of functions structured like that and it's not an option to rewrite
them all.

Lawrence Crowl calls (N)RVO the most important optimisation in C++, and it's
really sad that GCC doesn't apply NRVO even in those cases where there is only
one possible object returned per basic block, ie. where the compiler knows
which object will be returned by at the time of construction of each object.

It's even more sad that this report has been sitting here, unconfirmed and
ignored by the GCC developers, for 19 months.

[Bug c++/53637] NRVO not applied where there are two different variables involved

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-04
            Summary|NRVO not applied in         |NRVO not applied where
                   |branches when it could be   |there are two different
                   |                            |variables involved
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem is that GCC does not do NRVO when there are two different variables
used.  If the variable was the same, GCC would do the correct thing.
That is:
Foo bar(int i) {
  Foo result;
  if (i > 1) {
    return result;
  } else {
    return result;
  }
}

NRVO is applied.

[Bug c++/53637] NRVO not applied where there are two different variables involved

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|2015-02-04 00:00:00         |2021-12-16

[Bug c++/53637] NRVO not applied where there are two different variables involved

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:28db36e2cfca1b7106adc8d371600fa3a325c4e2

commit r14-1624-g28db36e2cfca1b7106adc8d371600fa3a325c4e2
Author: Jason Merrill <jason@redhat.com>
Date:   Wed Jun 7 05:15:02 2023 -0400

    c++: allow NRV and non-NRV returns [PR58487]

    Now that we support NRV from an inner block, we can also support non-NRV
    returns from other blocks, since once the NRV is out of scope a later
return
    expression can't possibly alias it.

    This fixes 58487 and half-fixes 53637: now one of the returns is elided,
but
    not the other.

    Fixing the remaining xfails in these testcases will require a very
different
    approach, probably involving a full tree/block walk from finalize_nrv, and
    check_return_expr only adding to a list of potential return variables.

            PR c++/58487
            PR c++/53637

    gcc/cp/ChangeLog:

            * cp-tree.h (INIT_EXPR_NRV_P): New.
            * semantics.cc (finalize_nrv_r): Check it.
            * name-lookup.h (decl_in_scope_p): Declare.
            * name-lookup.cc (decl_in_scope_p): New.
            * typeck.cc (check_return_expr): Allow non-NRV
            returns if the NRV is no longer in scope.

    gcc/testsuite/ChangeLog:

            * g++.dg/opt/nrv26.C: New test.
            * g++.dg/opt/nrv26a.C: New test.
            * g++.dg/opt/nrv27.C: New test.