public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Iain Sandoe <idsandoe@googlemail.com>
To: "Bin.Cheng" <amker.cheng@gmail.com>, Nathan Sidwell <nathan@acm.org>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH Coroutines]Insert the default return_void call at correct position
Date: Thu, 13 Feb 2020 18:20:00 -0000	[thread overview]
Message-ID: <AA7CFC2E-9A19-4461-9485-2722A7DB0038@googlemail.com> (raw)
In-Reply-To: <51A7E0F6-5491-4633-A40C-0234FF597E26@sandoe.co.uk>

Hello Bin, Nathan,

Iain Sandoe <iain@sandoe.co.uk> wrote:
>
>
> We are seeking to clarify the standard wording around this (and the cases  
> where
> unhandled_exception() returns - hopefully during the WG21 meeting this  
> week,
>
> FWIW, I think your interpretation makes sense here.

It’s not clear if the committee will have time to process wording changes  
needed for this during the current session, however, it is agreed that  
injecting the return_void at the closing brace of the user’s original  
function (your solution) is the correct approach.

So, from my point of view this patch DTRT and should be applied,

thanks
Iain


>> Thanks,
>> bin
>>
>> On Mon, Feb 3, 2020 at 1:55 PM bin.cheng <bin.cheng@linux.alibaba.com>  
>> wrote:
>>> Hi,
>>>
>>> Exception in coroutine is not correctly handled because the default
>>> return_void call is now inserted before the finish suspend point,
>>> rather than at the end of the original coroutine body.  This patch
>>> fixes the issue by generating following code:
>>> co_await promise.initial_suspend();
>>> try {
>>>  // The original coroutine body
>>>
>>>  promise.return_void(); // The default return_void call.
>>> } catch (...) {
>>>  promise.unhandled_exception();
>>> }
>>> final_suspend:
>>> // ...
>>>
>>> Bootstrap and test on x86_64.  Is it OK?
>>>
>>> Thanks,
>>> bin
>>>
>>> gcc/cp
>>> 2020-02-03  Bin Cheng  <bin.cheng@linux.alibaba.com>
>>>
>>>      * coroutines.cc (build_actor_fn): Factor out code inserting the
>>>      default return_void call to...
>>>      (morph_fn_to_coro): ...here, also hoist local var declarations.
>>>
>>> gcc/testsuite
>>> 2020-02-03  Bin Cheng  <bin.cheng@linux.alibaba.com>
>>>
>>>      * g++.dg/coroutines/torture/co-ret-15-default-return_void.C: New.


  reply	other threads:[~2020-02-13 18:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03  5:55 bin.cheng
2020-02-10  8:49 ` Bin.Cheng
2020-02-10 11:55   ` Iain Sandoe
2020-02-13 18:20     ` Iain Sandoe [this message]
2020-02-27 12:08 ` Nathan Sidwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AA7CFC2E-9A19-4461-9485-2722A7DB0038@googlemail.com \
    --to=idsandoe@googlemail.com \
    --cc=amker.cheng@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nathan@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).