[Bug c++/65869] Incorrect overload resolution in function return statement

2021-08-04 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80452,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91427

--- Comment #5 from Andrew Pinski  ---
Some interesting history here:

GCC7.5.0 and before accepted the code in C++11, C++14 and C++17 modes
GCC8+ reject the code in C++11, C++14, and C++17 modes with the following error
message:
: In function 'Derived foo()':
:14:10: error: cannot bind rvalue reference of type 'Base&&' to lvalue
of type 'Base'
   return result;
  ^~
:9:5: note:   initializing argument 1 of 'Derived::Derived(Base&&)'
 Derived(Base&&);
 ^~~

GCC11+ started to accept the code in C++20 mode.



GCC8 change was due to PR 80452.

GCC11 in C++20 mode seems most likely due to PR 91427.  The patch for PR 91427,
made it sound like it was defect report for earlier versions of the C++
standards too:
For the time being I'm limiting the new semantics to C++20 mode; since it
was moved as a DR, we will probably want to apply the change to other
standard modes as well once we have a better sense of the impact on
existing
code, probably in GCC 12.

[Bug c++/65869] Incorrect overload resolution in function return statement

2015-04-24 Thread botond at mozilla dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869

--- Comment #2 from Botond Ballo botond at mozilla dot com ---
(In reply to Marc Glisse from comment #1)
 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579

I don't think the resolution of this issue affects the validity of my code
example, i.e. it remains invalid.

The resolution of this issue makes the following code valid:

  Derived foo() {
Base result;
return result;
  }

(because it allows [class.copy] p32 to apply at all, where previously it didn't
apply because the type of the object to be copied, Base, was different from the
return type of the function Derived).

In my example, however:

  Derived foo() {
Derived result;
return result;
  }

p32 already applies, with or without the added wording. The problem is wording
further down in the paragraph which prevents the 'Derived(Base)' constructor
from being selected in the first overload resolution when the type of the
object is Derived.


[Bug c++/65869] Incorrect overload resolution in function return statement

2015-04-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-04-24
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Botond Ballo from comment #0)
   - However, p32 says that if the type of the first
 parameter of the selected constructor is not an rvalue
 reference to the object's type, then overload 
 resolution is performed again, treating the object as 
 an rvalue.

Typo, this should say lvalue.


[Bug c++/65869] Incorrect overload resolution in function return statement

2015-04-24 Thread botond at mozilla dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869

--- Comment #4 from Botond Ballo botond at mozilla dot com ---
   - The second overload resolution fails, because the only
 candidate (again, the explicit constructors are not
 candidates) has an rvalue reference parameter, which
 cannot bind to the lvalue that we're not treating the
 object as being.

This is also a typo, should say cannot bind to the lvalue that we're treating
the object as being.


[Bug c++/65869] Incorrect overload resolution in function return statement

2015-04-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65869

--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579