https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
Bug ID: 87150
Summary: move ctor wrongly chosen in return stmt (derived vs.
base)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
struct S1 { S1(S1 &&); };
struct S2: S1 {};
S1 f(S2 s) { return s; }
is accepted by GCC 8.1 but violates [class.copy.elision]/3, which dismisses the
move ctor if "the type of the first parameter of the selected constructor is
not an rvalue reference to the object’s type (possibly cv-qualified)" (and
which is the case here, where the object's type is S2 but the ctor parameter's
type is S1&&. (Referring to C++17, but wording is similar back to C++11, and
GCC's behavior is the same for -std=c++{11,14,17}.)
Checking on godbolt.org, the error of accepting the code appears to have been
introduced between GCC 7.3 and 8.1.
(Also see mail thread starting at
<http://lists.llvm.org/pipermail/cfe-dev/2018-August/059186.html> "return
lvalue move instead of copy?".)
