[Bug c++/103328] New: IC in remap_gimple_stmt, at tree-inline.c:1921

[Bug c++/103328] New: IC in remap_gimple_stmt, at tree-inline.c:1921

[avi@cloudius-systems.com]

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

            Bug ID: 103328
           Summary: IC in remap_gimple_stmt, at tree-inline.c:1921
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: avi@cloudius-systems.com
  Target Milestone: ---

Created attachment 51836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51836&action=edit
reduced reproducer. Thanks cvise.

The attached test case, compiled with 


   g++  -O2  --std=gnu++20   -c -o out.o raft-server.i


produces

during GIMPLE pass: einline
raft-server.i: In static member function ‘static seastar::futurize<T>::type
seastar::futurize<T>::invoke(Func&&, FuncArgs&& ...) [with Func = const
std::server_impl::send_message<std::variant<{anonymous}::append_request>
>({anonymous}::server_id,
std::variant<{anonymous}::append_request>)::<lambda(auto:1)>::<lambda()>&;
FuncArgs = {}; T = const
std::server_impl::send_message<std::variant<{anonymous}::append_request>
>({anonymous}::server_id,
std::variant<{anonymous}::append_request>)::<lambda(auto:1)>::<lambda()>&]’:
raft-server.i:405:7: internal compiler error: in remap_gimple_stmt, at
tree-inline.c:1921
  405 |   func();
      |   ~~~~^~
0xd11c4f remap_gimple_stmt
        ../../gcc/gcc/tree-inline.c:1921
0xd14357 copy_bb
        ../../gcc/gcc/tree-inline.c:2022
0xd15744 copy_cfg_body
        ../../gcc/gcc/tree-inline.c:3054
0xd15744 copy_body
        ../../gcc/gcc/tree-inline.c:3309
0xd189af expand_call_inline
        ../../gcc/gcc/tree-inline.c:5129
0xd19f59 gimple_expand_calls_inline
        ../../gcc/gcc/tree-inline.c:5319
0xd19f59 optimize_inline_calls(tree_node*)
        ../../gcc/gcc/tree-inline.c:5492
0x15ee69e early_inliner(function*)
        ../../gcc/gcc/ipa-inline.c:3007
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


The test case is invalid code now, but pre-reduction was valid (and accepted by
clang) and produced the same error.

Tested with current gcc releases/gcc-11 branch HEAD
(f62039efd679ffa8719732c71535457eb3ec61e0) + one patch backported
(daa9c6b015a33fa98af0ee7cd6919120248ab5f9).

[Bug c++/103328] ICE in remap_gimple_stmt, at tree-inline.c:1921

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |iains at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2021-11-19

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, so confirmed with -fno-checking.  With -fchecking I see

t.i:553:1: error: location references block not in block tree
  553 | } // namespace std
      | ^
_Coro_frameptr = 0B;
t.i:553:1: error: location references block not in block tree
_Coro_promise_live = 0;
t.i:553:1: error: location references block not in block tree
_Coro_gro_live = 0;
t.i:553:1: error: location references block not in block tree
_1 = 48;
t.i:553:1: error: location references block not in block tree
D.6221 = operator new (_1);
t.i:553:1: error: location references block not in block tree
...

so I wonder if that's an artifact of the reduction to invalid?  Can you
repeat the reduction in a way so the testcase keeps valid (accepted by clang)?

[Bug c++/103328] ICE in remap_gimple_stmt, at tree-inline.c:1921

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
1916      /* If STMT has a block defined, map it to the newly constructed
block.  */
1917      if (tree block = gimple_block (copy))
1918        {
1919          tree *n;
1920          n = id->decl_map->get (block);
1921          gcc_assert (n);

is where the -fno-checking ICE occurs.  Note that nicely maps to the complaints
with -fchecking.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.3
            Summary|ICE in remap_gimple_stmt,   |[11/12 Regression] ICE in
                   |at tree-inline.c:1921       |remap_gimple_stmt, at
                   |                            |tree-inline.c:1921 since
                   |                            |r11-7419-g0f161cc8494cf728
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r11-7419-g0f161cc8494cf728.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is a bad bisection, just change it like:
--- pr103328.C~ 2021-11-19 06:20:59.000000000 -0500
+++ pr103328.C  2021-11-19 06:21:57.000000000 -0500
@@ -530,7 +530,7 @@ void server_impl::send_message(server_id
   visit(
       [this, id](auto m) {
         _append_request_status[id].f.then(
-            [this, cm(m), cid = id] noexcept -> future<> {
+            [this, cm(m), cid = id] () noexcept -> future<> {
               auto m(cm);
               auto id = cid;
               try {
and you'll see it started earlier.
I then bisect it to r11-4386-g9e2256dcd481ffe3a8c79b65eba19fbb14b7ff8d
but that just means we need to use a replacement for __is_nothrow_constructible
to bisect it further.
I'm pretty sure the bug is in coroutines handling...

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #5 from Avi Kivity <avi@cloudius-systems.com> ---
Sure, I'll redo the reduction.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #6 from Avi Kivity <avi@cloudius-systems.com> ---
Unfortunately, clang doesn't accept the preprocessed source, only the original.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So can you perhaps check that g++ -O0 -std=gnu++20 -fno-checking -fno-inline
accepts it without errors while g++ -O2 -std=gnu++20 ICEs on it?

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #8 from Avi Kivity <avi@cloudius-systems.com> ---
Aha, I'll validate against g++ -O0.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #9 from Avi Kivity <avi@cloudius-systems.com> ---
btw, I also noticed these warnings:

raft/server.cc: In member function ‘virtual seastar::future<>
raft::server_impl::abort()’:
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::append_futures_1_2’
whose type uses the anonymous namespace [-Wsubobject-linkage]
  932 | }
      | ^
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::all_futures_1_2’
whose type uses the anonymous namespace [-Wsubobject-linkage]
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::D.579510_2_9’
whose type uses the anonymous namespace [-Wsubobject-linkage]
raft/server.cc:932:1: warning:
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame’ has a field
‘raft::server_impl::abort()::_ZN4raft11server_impl5abortEv.Frame::D.579509_2_9’
whose type uses the anonymous namespace [-Wsubobject-linkage]

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #10 from Avi Kivity <avi@cloudius-systems.com> ---
It's reducing with the stricter test, expect something in around 24 hours.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
The first stmt we complain on remains in the same function.  The functions
scope tree at the point of complaint is

{ Scope block #0 

  { Scope block #0 (unused) 
    struct coroutine_handle _Coro_actor_continue;

    { Scope block #0 (unused) 
      void (*<Te0e>) (struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
*) _Coro_resume_fn [value-expr: frame_ptr->_Coro_resume_fn];
      void (*<Te0e>) (struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
*) _Coro_destroy_fn [value-expr: frame_ptr->_Coro_destroy_fn];
      struct promise_type _Coro_promise [value-expr: frame_ptr->_Coro_promise];
      struct coroutine_handle _Coro_self_handle [value-expr:
frame_ptr->_Coro_self_handle];
      const struct ._anon_5 * const __closure [value-expr:
frame_ptr->__closure];
      short unsigned int _Coro_resume_index [value-expr:
frame_ptr->_Coro_resume_index];
      bool _Coro_frame_needs_free [value-expr:
frame_ptr->_Coro_frame_needs_free];
      bool _Coro_initial_await_resume_called [value-expr:
frame_ptr->_Coro_initial_await_resume_called];

      { Scope block #0 (unused) 
        struct suspend_never Is [value-expr: frame_ptr->Is_1_1];

      }

      { Scope block #0 
        void resume.6 = <<< error >>>;
        void destroy.6 = <<< error >>>;
        void resume.4 = <<< error >>>;
        void destroy.4 = <<< error >>>;
        void resume.2 = <<< error >>>;
        void destroy.2 = <<< error >>>;
        void coro.delete.frame = <<< error >>>;
        void coro.delete.promise = <<< error >>>;
        void actor.continue.ret = <<< error >>>;
        void actor.suspend.ret = <<< error >>>;
        void actor.begin = <<< error >>>;
        void final.suspend = <<< error >>>;
        const struct tagged_id cid [value-expr: __closure->__cid];
        const struct append_request cm [value-expr: __closure->__cm];
        struct server_impl * const this [value-expr: __closure->__this];

        { Scope block #0 (unused) 
          struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
* _Coro_frameptr;
          bool _Coro_promise_live;
          bool _Coro_gro_live;

          { Scope block #0 (unused) 

          }

        }

      }

    }

  }

}

while at the point we lower control flow and set gimple_block it is

{ Scope block #0 

  { Scope block #0 (unused) 
    struct coroutine_handle _Coro_actor_continue;

    { Scope block #0 (unused) 
      void (*<Te0e>) (struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
*) _Coro_resume_fn [value-expr: frame_ptr->_Coro_resume_fn];
      void (*<Te0e>) (struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
*) _Coro_destroy_fn [value-expr: frame_ptr->_Coro_destroy_fn];
      struct promise_type _Coro_promise [value-expr: frame_ptr->_Coro_promise];
      struct coroutine_handle _Coro_self_handle [value-expr:
frame_ptr->_Coro_self_handle];
      const struct ._anon_5 * const __closure [value-expr:
frame_ptr->__closure];
      short unsigned int _Coro_resume_index [value-expr:
frame_ptr->_Coro_resume_index];
      bool _Coro_frame_needs_free [value-expr:
frame_ptr->_Coro_frame_needs_free];
      bool _Coro_initial_await_resume_called [value-expr:
frame_ptr->_Coro_initial_await_resume_called];

      { Scope block #0 
        void resume.6 = <<< error >>>;
        void destroy.6 = <<< error >>>;
        void resume.4 = <<< error >>>;
        void destroy.4 = <<< error >>>;
        void resume.2 = <<< error >>>;
        void destroy.2 = <<< error >>>;
        void coro.delete.frame = <<< error >>>;
        void coro.delete.promise = <<< error >>>;
        void actor.continue.ret = <<< error >>>;
        void actor.suspend.ret = <<< error >>>;
        void actor.begin = <<< error >>>;
        void final.suspend = <<< error >>>;
        const struct tagged_id cid [value-expr: __closure->__cid];
        const struct append_request cm [value-expr: __closure->__cm];
        struct server_impl * const this [value-expr: __closure->__this];

        { Scope block #0 
          struct append_request m [value-expr: frame_ptr->m_2_3];
          struct tagged_id id [value-expr: frame_ptr->id_2_3];

          { Scope block #0 (unused) 
            struct awaiter Aw0 [value-expr: frame_ptr->Aw0_3_4];

          }

        }

      }

      { Scope block #0 (unused) 
        struct suspend_never Is [value-expr: frame_ptr->Is_1_1];

      }

    }

  }

}

The block we associate with the stmt is

{ Scope block #0 (unused) 
  struct awaiter Aw0 [value-expr: frame_ptr->Aw0_3_4];

}

it looks like there's mangling of the block tree happening somehow.
We run into

/* Lower a bind_expr TSI.  DATA is passed through the recursion.  */

static void
lower_gimple_bind (gimple_stmt_iterator *gsi, struct lower_data *data)
{
  tree old_block = data->block;
  gbind *stmt = as_a <gbind *> (gsi_stmt (*gsi));
  tree new_block = gimple_bind_block (stmt);

  if (new_block)
    {
      if (new_block == old_block)
        {
          /* The outermost block of the original function may not be the
             outermost statement chain of the gimplified function.  So we
             may see the outermost block just inside the function.  */
          gcc_assert (new_block == DECL_INITIAL (current_function_decl));
          new_block = NULL;
        }
      else
        { 
          /* We do not expect to handle duplicate blocks.  */
          gcc_assert (!TREE_ASM_WRITTEN (new_block));
          TREE_ASM_WRITTEN (new_block) = 1;

          /* Block tree may get clobbered by inlining.  Normally this would
             be fixed in rest_of_decl_compilation using block notes, but
             since we are not going to emit them, it is up to us.  */
          BLOCK_CHAIN (new_block) = BLOCK_SUBBLOCKS (old_block);
          BLOCK_SUBBLOCKS (old_block) = new_block;
          BLOCK_SUBBLOCKS (new_block) = NULL_TREE;
          BLOCK_SUPERCONTEXT (new_block) = old_block;

with BLOCK_CHAIN (new_block) != NULL and lose those blocks.  old_block
is the outermost block here.

It looks like the BIND_EXPR nesting does not match the BLOCK tree nesting
and things go wrong from there.  The IL looks like

{
  [t.i:533:13] try
    {
      [t.i:533:13] {
        struct
_ZZZNSt11server_impl12send_messageISt7variantIJN12_GLOBAL__N_114append_requestEEEEEvNS2_8internal9tagged_idINS2_13server_id_tagEEET_ENKUlS9_E_clIS3_EEDaS9_ENKUlvE_clEv.Frame
* _Coro_frameptr;
        bool _Coro_promise_live;
        bool _Coro_gro_live;

        [t.i:533:13] _Coro_frameptr = 0B;
        [t.i:533:13] _Coro_promise_live = 0;
        [t.i:533:13] _Coro_gro_live = 0;
        [t.i:533:13] _1 = .CO_FRAME (48, _Coro_frameptr);
        [t.i:533:13] _Coro_frameptr = operator new (_1);
        [t.i:533:13] try
          {
            [t.i:533:13] [t.i:533:13] _Coro_frameptr->_Coro_frame_needs_free =
1;
            [t.i:533:13] [t.i:533:13] _Coro_frameptr->_Coro_resume_fn =
operator();
            [t.i:533:13] [t.i:533:13] _Coro_frameptr->_Coro_destroy_fn =
operator();
            [t.i:533:13] [t.i:533:13] _Coro_frameptr->__closure = __closure;
            [t.i:533:13] {
              [t.i:533:13] _2 = [t.i:533:13] &[t.i:533:13]
_Coro_frameptr->_Coro_promise;
              [t.i:533:13]
seastar::internal::coroutine_traits_base<>::promise_type::get_return_object
(_2);
              [t.i:533:13] [t.i:533:13] _Coro_frameptr->_Coro_resume_index = 0;
              [t.i:533:13]
std::server_impl::send_message<std::variant<{anonymous}::append_request>
>({anonymous}::server_id,
std::variant<{anonymous}::append_request>)::<lambda(auto:1)>::<lambda()>::operator()
(_Coro_frameptr);
              [t.i:533:13] return <retval>;
            }
          }
        catch
          {
            [t.i:533:13] catch (NULL)
              {
                [t.i:533:13] try
                  {
                    [t.i:533:13] _3 = __builtin_eh_pointer (0);
                    [t.i:533:13] __cxa_begin_catch (_3);
                    [t.i:533:13] operator delete (_Coro_frameptr);
                    [t.i:533:13] __cxa_rethrow ();
                  }
                finally
                  {
                    [t.i:533:13] __cxa_end_catch ();
                  }
              }
          }
      }
    }
  catch
    {
      <<<eh_must_not_throw (terminate)>>>
    }
}

IIRC there's no "verification" of IL BIND_EXPR/gimple_block nesting vs.
DECL_INITIAL block tree nesting.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Basically with lower_gimple_bind we re-wire the BLOCK tree to match the
GIMPLE_BLOCK IL nesting.  Whatever gets "unreachable" in that process is
"lost".
The following shows this, but it seems it is expected that we lose some blocks,
just not that we lose used ones (so I use TREE_USED to mark
the blocks we record in stmts and only check those).  Interestingly then
it doesn't trigger.  Instead it looks like the BIND_EXPR tree contains
BLOCKs not in the initial BLOCK tree!?

{ Scope block #0 
  struct _ZNSt11server_impl8io_fiberEN12_GLOBAL__N_114append_requestE.Frame *
_Coro_frameptr;
  bool _Coro_promise_live;
  bool _Coro_gro_live;

  { Scope block #0 

  }

}

for example.

diff --git a/gcc/gimple-low.c b/gcc/gimple-low.c
index 7d9b3df2ffb..b0ae15f0368 100644
--- a/gcc/gimple-low.c
+++ b/gcc/gimple-low.c
@@ -77,6 +77,7 @@ static void lower_gimple_return (gimple_stmt_iterator *,
struct lower_data *);
 static void lower_builtin_setjmp (gimple_stmt_iterator *);
 static void lower_builtin_posix_memalign (gimple_stmt_iterator *);

+extern void collect_subblocks (hash_set<tree> *, tree);

 /* Lower the body of current_function_decl from High GIMPLE into Low
    GIMPLE.  */
@@ -96,6 +97,11 @@ lower_function_body (void)
   gcc_assert (gimple_seq_first (body) == gimple_seq_last (body)
              && gimple_code (gimple_seq_first_stmt (body)) == GIMPLE_BIND);

+  hash_set<tree> blocks;
+  collect_subblocks (&blocks, DECL_INITIAL (current_function_decl));
+  for (auto i = blocks.begin (); i != blocks.end (); ++i)
+    TREE_USED (*i) = 0;
+
   memset (&data, 0, sizeof (data));
   data.block = DECL_INITIAL (current_function_decl);
   BLOCK_SUBBLOCKS (data.block) = NULL_TREE;
@@ -165,6 +171,17 @@ lower_function_body (void)
     = blocks_nreverse (BLOCK_SUBBLOCKS (data.block));

   clear_block_marks (data.block);
+
+  hash_set<tree> blocks_after;
+  collect_subblocks (&blocks_after, DECL_INITIAL (current_function_decl));
+  for (auto i = blocks.begin (); i != blocks.end (); ++i)
+    if (TREE_USED (*i) && !blocks_after.contains (*i))
+      gcc_unreachable ();
+  for (auto i = blocks_after.begin (); i != blocks_after.end (); ++i)
+    if (!blocks.contains (*i))
+      gcc_unreachable ();
+
+
   data.return_statements.release ();
   return 0;
 }
@@ -248,6 +265,7 @@ lower_stmt (gimple_stmt_iterator *gsi, struct lower_data
*data)
   gimple *stmt = gsi_stmt (*gsi);

   gimple_set_block (stmt, data->block);
+  TREE_USED (data->block) = 1;

   switch (gimple_code (stmt))
     {
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index cde606e1a40..719941dea42 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -5396,7 +5396,7 @@ verify_expr_location (tree *tp, int *walk_subtrees, void
*data)

 /* Insert all subblocks of BLOCK into BLOCKS and recurse.  */

-static void
+void
 collect_subblocks (hash_set<tree> *blocks, tree block)
 {
   tree t;

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
The checking patch also trigers on coroutines.exp testing (as expected).

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the BLOCK is lost somewhere between CFG build (still OK as by
verify_gimple_in_cfg) and free_lang_data where it is lost.

Oh, so the BLOCK in question is used in two different functions BIND_EXPRs
and thus during the lowering of another function the BLOCK tree of the first
function referencing the BLOCK is garbled.

(gdb) p cfun->decl->decl_common.initial 
$18 = <block 0x7ffff6478300>
(gdb) p cfun->decl->decl_common.initial->block.supercontext 
$19 = <block 0x7ffff6478360>
(gdb) p cfun->decl->decl_common.initial->block.supercontext->block.supercontext
$20 = <block 0x7ffff6478600>
(gdb) p
cfun->decl->decl_common.initial->block.supercontext->block.supercontext->block.supercontext->block.supercontext
$21 = <function_decl 0x7ffff6483d00 operator()>

  gcc_assert (BLOCK_SUPERCONTEXT (DECL_INITIAL (current_function_decl))
              == current_function_decl);

at the start of lower_function_body will trip on this.  So somewhere coroutines
functions are constructed we fail to copy the BLOCK tree of shared parts.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
OK. I need to see where I slipped up - we are supposed to extract the outlined
portion of the function and then wrap that in the various machinery specified
in the std.

However, blocks associated with parms could possibly be referred to twice (so
that the location of the parms is available for debugging the outlined
function).  Perhaps a missing copy_node().

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
And

static void
verify_scope_blocks (tree block, tree supercontext)
{
  gcc_assert (BLOCK_SUPERCONTEXT (block) == supercontext);
  for (tree t = BLOCK_SUBBLOCKS (block); t; t = BLOCK_CHAIN (t))
    verify_scope_blocks (t, block);
}

with checking inside gimplify_function_tree

  verify_scope_blocks (DECL_INITIAL (current_function_decl),
                       current_function_decl);

ICEs first with

#1  0x00000000013ca52a in verify_scope_blocks (block=<block 0x7ffff63cacc0>, 
    supercontext=<block 0x7ffff63cad20>)
    at /home/rguenther/src/gcc3/gcc/gimplify.c:16044
16044     gcc_assert (BLOCK_SUPERCONTEXT (block) == supercontext);
gdb) p cfun->decl
$1 = <function_decl 0x7ffff63b5600 io_fiber>
(gdb) p
block->block.supercontext->block.supercontext->block.supercontext->block.supercontext
$12 = <tree 0x0>

possibly 'block' was added into another function, but it roots at NULL...

somehow all the BLOCK setup is done in poplevel() but I can't see what's wrong.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi@cloudius-systems.com]

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

--- Comment #17 from Avi Kivity <avi@cloudius-systems.com> ---
Created attachment 51843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51843&action=edit
valid-code reproducer (compiles with -O0)

Uploaded a valid-code reproducer (if you don't mind warnings). Compiles with
-O0, ICEs with -O2.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[piotr.grabowski at scylladb dot com]

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

Piotr Grabowski <piotr.grabowski at scylladb dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotr.grabowski at scylladb dot co
                   |                            |m

--- Comment #18 from Piotr Grabowski <piotr.grabowski at scylladb dot com> ---
Created attachment 52520
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52520&action=edit
smaller reproducer (-g flag required)

Uploading a smaller 30-line reproducer, reduced independently from Avi, but
started from the same origin file. The error messages are the same as previous
reproducers. It fails to compile with all optimization levels I checked.

Compiled with (-g required):

   g++ -g -std=c++20 attached.cpp

For g++ (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) and "-g -std=c++20 -fchecking"
it fails with:

...
pr103328_smaller.cpp:30:13: error: location references block not in block tree
... (repeated multiple times)
pr103328_smaller.cpp:30: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccdJXVFM.out file, please attach this to
your bugreport.

For "g++ (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)" and "-g -std=c++20
-fno-checking" it fails with:

during RTL pass: final
pr103328_smaller.cpp: In function ‘void
foo::f()::<lambda()>::operator()(foo::f()::<lambda()>::_ZZN3foo1fEvENKUlvE_clEv.Frame*)’:
pr103328_smaller.cpp:24:17: internal compiler error: Segmentation fault
   24 |   auto lambda = [this]() noexcept -> task {
      |                 ^
Please submit a full bug report,

For "g++
(Compiler-Explorer-Build-gcc-cb3afcd2a380f2fb6c490f2c1318f76402eab43a-binutils-2.36.1)
12.0.1 20220217 (experimental)" and "-g -std=c++20 -fno-checking" it fails
with:

during RTL pass: final
<source>: In function 'void
foo::f()::<lambda()>::operator()(foo::f()::<lambda()>::_ZZN3foo1fEvENKUlvE_clEv.Frame*)':
<source>:24:17: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.cc:1467
   24 |   auto lambda = [this]() noexcept -> task {
      |                 ^
0x217c1f9 internal_error(char const*, ...)
        ???:0
0x6f3eaf tree_check_failed(tree_node const*, char const*, int, char const*,
...)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).

For "g++
(Compiler-Explorer-Build-gcc-cb3afcd2a380f2fb6c490f2c1318f76402eab43a-binutils-2.36.1)
12.0.1 20220217 (experimental)" and "-g -std=c++20 -fchecking" it fails with:

...
<source>:30:13: error: location references block not in block tree
... (repeated multiple times)
during IPA pass: *free_lang_data
<source>:30:13: internal compiler error: verify_gimple failed
0x217c1f9 internal_error(char const*, ...)
        ???:0
0x1188a85 verify_gimple_in_cfg(function*, bool)
        ???:0

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[gcc at bmevers dot de]

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

Benno Evers <gcc at bmevers dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc at bmevers dot de

--- Comment #19 from Benno Evers <gcc at bmevers dot de> ---
I've independently encountered this issue, and investigated a bit using the
reproducer by Avi Kivity.

>From what I've found, the issue is when inlining the function body into the
actor function in `coro_rewrite_function_body()`:

    /* Append the original function body.  */
    add_stmt (fnbody);

it will contain a reference to the top-level BLOCK of the user-provided
function.

However, when the actor function gets built it is not actually the "current"
function being finished, so `current_function_decl` points to the lambda (that
is currently being morphed into the ramp) instead.

Later on when we finish the lambda in `poplevel()` in decl.cc, we (may) assign
the DECL_INITIAL for that function from the `current_binding_level` which still
points to the last top-level block of the original function that is also used
by `fnbody`.

    subblocks = functionbody >= 0 ? current_binding_level->blocks : 0;
    // [...]
    DECL_INITIAL (current_function_decl) = block ? block : subblocks;


So we end up with the same `tree` being used in two different functions, and
then during gimple lowering bad things happen (in particular, the `subblocks`
set by the actor function are overwritten while lowering the ramp function)

The following change fixed the segfault on both reproducers on a local build.
I'm not too familiar with the GCC codebase so there's probably a better way to
handle the issue, but if the approach looks reasonable I'm happy to submit a
full patch.


--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -4541,6 +4541,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree
*destroyer)
   BLOCK_VARS (top_block) = BIND_EXPR_VARS (ramp_bind);
   BLOCK_SUBBLOCKS (top_block) = NULL_TREE;

+  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.  */

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[gcc at bmevers dot de]

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

--- Comment #20 from Benno Evers <gcc at bmevers dot de> ---
Created attachment 52611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52611&action=edit
Possible fix

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728

[avi at scylladb dot com]

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

--- Comment #21 from Avi Kivity <avi at scylladb dot com> ---
Benno, many thanks for the fix. Please consider posting it to gcc-patches as
that may speed up review and merging.

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[avi at scylladb dot com]

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

--- Comment #22 from Avi Kivity <avi at scylladb dot com> ---
Maintainers, please review the patch posted in [1].


[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591907.html

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 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:0847ad33b908af88bca1e6980d0b977316d05e18

commit r12-7971-g0847ad33b908af88bca1e6980d0b977316d05e18
Author: Benno Evers <benno.evers@tenzir.com>
Date:   Sat Apr 2 17:22:33 2022 +0100

    c++: Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

    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>

[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[avi at scylladb dot com]

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

--- Comment #24 from Avi Kivity <avi at scylladb dot com> ---
Many thanks for the patch and the commit. Can we have it backported to 11.x?

[Bug c++/103328] [11 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:a77c9efdeb9ecad14ecca73db0e45fcd9d884382

commit r11-9789-ga77c9efdeb9ecad14ecca73db0e45fcd9d884382
Author: Benno Evers <benno.evers@tenzir.com>
Date:   Sat Apr 2 17:22:33 2022 +0100

    c++: Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

    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>
    (cherry picked from commit 0847ad33b908af88bca1e6980d0b977316d05e18)

[Bug c++/103328] [11 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
      Known to fail|11.2.1                      |11.2.0
      Known to work|                            |11.2.1

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
Done and fixed.

[Bug c++/103328] [11 Regression] ICE in remap_gimple_stmt with coroutines since r11-7419-g0f161cc8494cf728

[avi at scylladb dot com]

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

--- Comment #27 from Avi Kivity <avi at scylladb dot com> ---
Wonderful, thank you.