https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93929
Bug ID: 93929
Summary: In copy elision cases, fallback to lvalue even if
rvalue overload resolution succeeds
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Example:
struct X {
X();
X(X const&);
X(X&&) = delete;
};
X make() {
X a;
return a;
}
This should be ill-formed. The rules are:
> If the first overload resolution fails or was not performed, overload
> resolution is performed again, considering the expression or operand as an
> lvalue.
and
> If a best viable function exists and is unique, overload resolution succeeds
> and produces it as the result.
Overload resolution considering "a" as an rvalue finds the move constructor.
That's successful overload resolution - we should pick it, and then reject the
program (edg and msvc do this). But gcc (and clang) considers this as failing
overload resolution and falls back to pick the copy constructor.
