public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Benno Evers <benno.martin.evers@googlemail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: Fix ICE due to shared BLOCK node in coroutine generation [PR103328]
Date: Fri, 1 Apr 2022 15:07:42 -0400	[thread overview]
Message-ID: <dbf2380c-6726-6a50-bc7a-be59655606a4@redhat.com> (raw)
In-Reply-To: <CAEQVFRFkapOFWy1b8XR3rXvBH4yO9OtubQS=2OEfECMLB2qfEQ@mail.gmail.com>

On 3/30/22 09:06, Benno Evers via Gcc-patches wrote:
> From: Benno Evers <benno.evers@tenzir.com>
> 
> When finishing a function that is a coroutine, the function is
> transformed into a "ramp" function, and the original user-provided
> function body gets moved into a newly created "actor" function.
> 
> In this case `current_function_decl` points to the ramp function,
> but `current_binding_level->blocks` would still point to the
> scope block of the user-provided function body in the actor function,
> so when the ramp function was finished during `poplevel()` in decl.cc,
> we could end up with that block being reused as the `DECL_INITIAL()` of
> the ramp function:
> 
>      subblocks = functionbody >= 0 ? current_binding_level->blocks : 0;
>      // [...]
>      DECL_INITIAL (current_function_decl) = block ? block : subblocks;
> 
> This block would then be independently modified by subsequent passes
> touching either the ramp or the actor function, potentially causing
> an ICE depending on the order and function of these passes.
> 
> gcc/cp/ChangeLog:
> 
>          PR c++/103328
>      * coroutines.cc (morph_fn_to_coro): Reset
>        current_binding_level->blocks.
> 
> gcc/testsuite/ChangeLog:
> 
>          PR c++/103328
>          * g++.dg/coroutines/pr103328.C: New test.
> 
> Co-Authored-By: Iain Sandoe <iain@sandoe.co.uk>

Looks like you also need a DCO sign-off; see

https://gcc.gnu.org/contribute.html#legal

for more information.

> ---
>   gcc/cp/coroutines.cc                       |  3 ++
>   gcc/testsuite/g++.dg/coroutines/pr103328.C | 32 ++++++++++++++++++++++
>   2 files changed, 35 insertions(+)
>   create mode 100644 gcc/testsuite/g++.dg/coroutines/pr103328.C
> 
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 23dc28271a4..ece30c905e8 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -4541,6 +4541,9 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
> *destroyer)

gmail is breaking your patch with word wrap; see

https://www.kernel.org/doc/html/v4.17/process/email-clients.html

for information about ways to work around this, or just use an attachment.

>     BLOCK_VARS (top_block) = BIND_EXPR_VARS (ramp_bind);
>     BLOCK_SUBBLOCKS (top_block) = NULL_TREE;
> 
> +  /* Reset the current binding level to the ramp function */
> +  current_binding_level->blocks = top_block;
> +
>     /* The decl_expr for the coro frame pointer, initialize to zero so that we
>        can pass it to the IFN_CO_FRAME (since there's no way to pass a type,
>        directly apparently).  This avoids a "used uninitialized" warning.  */
> diff --git a/gcc/testsuite/g++.dg/coroutines/pr103328.C
> b/gcc/testsuite/g++.dg/coroutines/pr103328.C
> new file mode 100644
> index 00000000000..56fb54ab316
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/coroutines/pr103328.C
> @@ -0,0 +1,32 @@
> +// { dg-additional-options "-g" }
> +
> +#include <coroutine>
> +
> +struct task {
> +  struct promise_type {
> +    task get_return_object() { return {}; }
> +    std::suspend_never initial_suspend() { return {}; }
> +    std::suspend_never final_suspend() noexcept { return {}; }
> +    void unhandled_exception() {}
> +  };
> +  bool await_ready() { return false; }
> +  void await_suspend(std::coroutine_handle<> h) {}
> +  void await_resume() {}
> +};
> +
> +template <typename Func>
> +void call(Func func) { func(); }
> +
> +class foo {
> +  void f();
> +  task g();
> +};
> +
> +void foo::f() {
> +  auto lambda = [this]() noexcept -> task {
> +      co_await g();
> +  };
> +  (void)call<decltype(lambda)>;
> +}
> +
> +int main() {}


      reply	other threads:[~2022-04-01 19:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 13:06 Benno Evers
2022-04-01 19:07 ` Jason Merrill [this message]

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=dbf2380c-6726-6a50-bc7a-be59655606a4@redhat.com \
    --to=jason@redhat.com \
    --cc=benno.martin.evers@googlemail.com \
    --cc=gcc-patches@gcc.gnu.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).