[Bug target/120450] New: GCN offloading: ICE 'during RTL pass: expand', 'in assign_temp, at function.cc:990' for C++ 'std::flat_map', 'std::flat_multimap'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

            Bug ID: 120450
           Summary: GCN offloading: ICE 'during RTL pass: expand', 'in
                    assign_temp, at function.cc:990' for C++
                    'std::flat_map', 'std::flat_multimap'
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, openmp
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: ams at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    kcy at codesourcery dot com
  Target Milestone: ---
            Target: GCN

In an OpenMP 'target' region, constructing a C++23-new 'std::flat_map',
'std::flat_multimap' is fine for host and nvptx offloading compilation (and
appears to behave as expected), but we ICE for GCN offloading compilation. 
More elaborate test cases to appear soon, but here's a simple '-O0' reproducer:

    #include <flat_map>
    int main (void)
    {
      #pragma omp target
      {
        std::flat_map<int,int> m;
      }
      return 0;
    }

    during RTL pass: expand
    In member function ‘__ct ’,
        inlined from ‘__ct ’ at
[...]/install/include/c++/16.0.0/flat_map:156:54,
        inlined from ‘__ct ’ at
[...]/install/include/c++/16.0.0/flat_map:1431:11,
        inlined from ‘main._omp_fn.0’ at
source-gcc/libgomp/testsuite/libgomp.c++/concurrent-flat_multimap.C:41:48:
    [...]/install/include/c++/16.0.0/flat_map:160:9: internal compiler error:
in assign_temp, at function.cc:990
      160 |       : _M_cont(), _M_comp(__comp)
          |         ^
    0x20b1426 internal_error(char const*, ...)
            [...]/source-gcc/gcc/diagnostic-global-context.cc:517
    0xa3b67c fancy_abort(char const*, int, char const*)
            [...]/source-gcc/gcc/diagnostic.cc:1815
    0x7ac610 assign_temp(tree_node*, int, int)
            [...]/source-gcc/gcc/function.cc:990
    0xc42857 expand_constructor
            [...]/source-gcc/gcc/expr.cc:9447
    0xc2dcd8 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
            [...]/source-gcc/gcc/expr.cc:11754
    0xc41da3 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
            [...]/source-gcc/gcc/expr.cc:9529
    0xc41da3 expand_normal(tree_node*)
            [...]/source-gcc/gcc/expr.h:329
    0xc41da3 store_field
            [...]/source-gcc/gcc/expr.cc:8246
    0xc3d2a9 expand_assignment(tree_node*, tree_node*, bool)
            [...]/source-gcc/gcc/expr.cc:6334
    0xaede1e expand_gimple_stmt_1
            [...]/source-gcc/gcc/cfgexpand.cc:4289
    0xaede1e expand_gimple_stmt
            [...]/source-gcc/gcc/cfgexpand.cc:4370
    0xaf2d98 expand_gimple_basic_block
            [...]/source-gcc/gcc/cfgexpand.cc:6433
    0xaf5186 execute
            [...]/source-gcc/gcc/cfgexpand.cc:7181

It appears to share some similarity with PR114572 '[OpenMP] "internal compiler
error: in assign_temp" with assignment operator and lastprivate clause', but
that one has been fixed long ago.