public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
@ 2020-05-26 20:31 lewissbaker.opensource at gmail dot com
  2020-05-27 19:42 ` [Bug c++/95346] " iains at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: lewissbaker.opensource at gmail dot com @ 2020-05-26 20:31 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 95346
           Summary: [coroutines] coroutine return-type should be
                    initialised with rvalue if different from
                    get_return_object() return-type
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lewissbaker.opensource at gmail dot com
  Target Milestone: ---

If I have the following code:

----------
#include <coroutine>

struct task {
    struct promise_type {
        task get_return_object();
        void return_void();
        void unhandled_exception();
        std::suspend_always initial_suspend() noexcept;
        std::suspend_always final_suspend() noexcept;
    };
};

struct wrapper {
    using promise_type = task::promise_type;
    wrapper(task&&);
};

wrapper f() {
    co_return;
}
----------


Then building with GCC 10.0 and GCC trunk with -std=c++20 -fcoroutines fails
with the following compile-error:


x86-64 gcc (trunk)
-O3 -std=c++2a -Wall -fcoroutines
1
<Compilation failed>
x86-64 gcc (trunk) - 368ms
<source>: In function 'wrapper f()':

error: cannot bind rvalue reference of type 'task&&' to lvalue of type 'task'
   30 | }
      | ^
note:   initializing argument 1 of 'wrapper::wrapper(task&&)'
   25 |     wrapper(task&&);


I think the return-value of a coroutine should be initialised with an
rvalue-reference to the object returned from get_return_object() if the
two objects have different types. GCC seems to be trying to initialise
the return-value using an lvalue-reference to the object returned from
get_return_object().

Both Clang and MSVC accept this code, while GCC does not.
See https://godbolt.org/z/4RRtaL

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/95346] [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
  2020-05-26 20:31 [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type lewissbaker.opensource at gmail dot com
@ 2020-05-27 19:42 ` iains at gcc dot gnu.org
  2020-06-04 18:26 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: iains at gcc dot gnu.org @ 2020-05-27 19:42 UTC (permalink / raw)
  To: gcc-bugs

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |iains at gcc dot gnu.org
   Target Milestone|---                         |10.2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-05-27
           Keywords|                            |rejects-valid
     Ever confirmed|0                           |1

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
thanks for the report, I have a fix for this in my patch queue (but the
reproducer test-case is very useful).

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/95346] [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
  2020-05-26 20:31 [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type lewissbaker.opensource at gmail dot com
  2020-05-27 19:42 ` [Bug c++/95346] " iains at gcc dot gnu.org
@ 2020-06-04 18:26 ` cvs-commit at gcc dot gnu.org
  2020-06-10 20:59 ` cvs-commit at gcc dot gnu.org
  2020-06-12 17:55 ` iains at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-04 18:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:4f2d05ef0142d269964e165c14c6f7fe4bdfd5a3

commit r11-952-g4f2d05ef0142d269964e165c14c6f7fe4bdfd5a3
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Thu Jun 4 17:14:37 2020 +0100

    coroutines: Fix missed ramp function return copy elision [PR95346].

    Confusingly, "get_return_object ()" can do two things:
    - Firstly it can provide the return object for the ramp function (as
      the name suggests).
    - Secondly if the type of the ramp function is different from that
      of the get_return_object call, this is used as a single parameter
      to a CTOR for the ramp's return type.

    In the first case we can rely on finish_return_stmt () to do the
    necessary processing for copy elision.
    In the second case, we should have passed a prvalue to the CTOR as
    per the standard comment, but I had omitted the rvalue () call.  Fixed
    thus.

    gcc/cp/ChangeLog:

            PR c++/95346
            * coroutines.cc (morph_fn_to_coro): Ensure that the get-
            return-object is constructed correctly; When it is not the
            final return value, pass it to the CTOR of the return type
            as an rvalue, per the standard comment.

    gcc/testsuite/ChangeLog:

            PR c++/95346
            * g++.dg/coroutines/pr95346.C: New test.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/95346] [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
  2020-05-26 20:31 [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type lewissbaker.opensource at gmail dot com
  2020-05-27 19:42 ` [Bug c++/95346] " iains at gcc dot gnu.org
  2020-06-04 18:26 ` cvs-commit at gcc dot gnu.org
@ 2020-06-10 20:59 ` cvs-commit at gcc dot gnu.org
  2020-06-12 17:55 ` iains at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-06-10 20:59 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4

commit r10-8269-g5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Jun 10 08:12:32 2020 +0100

    coroutines: Fix missed ramp function return copy elision [PR95346].

    Confusingly, "get_return_object ()" can do two things:
    - Firstly it can provide the return object for the ramp function (as
      the name suggests).
    - Secondly if the type of the ramp function is different from that
      of the get_return_object call, this is used as a single parameter
      to a CTOR for the ramp's return type.

    In the first case we can rely on finish_return_stmt () to do the
    necessary processing for copy elision.
    In the second case, we should have passed a prvalue to the CTOR as
    per the standard comment, but I had omitted the rvalue () call.  Fixed
    thus.

    gcc/cp/ChangeLog:

            PR c++/95346
            * coroutines.cc (morph_fn_to_coro): Ensure that the get-
            return-object is constructed correctly; When it is not the
            final return value, pass it to the CTOR of the return type
            as an rvalue, per the standard comment.

    gcc/testsuite/ChangeLog:

            PR c++/95346
            * g++.dg/coroutines/pr95346.C: New test.

    (cherry picked from commit 4f2d05ef0142d269964e165c14c6f7fe4bdfd5a3)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/95346] [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type
  2020-05-26 20:31 [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type lewissbaker.opensource at gmail dot com
                   ` (2 preceding siblings ...)
  2020-06-10 20:59 ` cvs-commit at gcc dot gnu.org
@ 2020-06-12 17:55 ` iains at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: iains at gcc dot gnu.org @ 2020-06-12 17:55 UTC (permalink / raw)
  To: gcc-bugs

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed for master and 10.2.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-06-12 17:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-26 20:31 [Bug c++/95346] New: [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type lewissbaker.opensource at gmail dot com
2020-05-27 19:42 ` [Bug c++/95346] " iains at gcc dot gnu.org
2020-06-04 18:26 ` cvs-commit at gcc dot gnu.org
2020-06-10 20:59 ` cvs-commit at gcc dot gnu.org
2020-06-12 17:55 ` iains at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).