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?".)