[Bug middle-end/92876] ICE in expand_UNIQUE, at internal-fn.c:2599

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
And: The ICE occurs for
  .data_dep.1_7 = .UNIQUE (OACC_HEAD_MARK, 0, 1, 132);

And then one runs inside expand_UNIQUE into:
  switch (kind)
    {
    default:
      gcc_unreachable ();

This one is generated in omp-low.c either by lower_oacc_head_mark or by
lower_oacc_loop_marker, which can also generate IFN_UNIQUE_OACC_TAIL_MARK.

Those two are supposed to get processed by omp-offload.c's
oacc_loop_discover_walk and execute_oacc_device_lower, where the latter is
supposed to remove them.

But as offloading does not happen, the "s" routine simply gets inlined – and
one gets an ICE.

The next ICE is then in the same function for IFN_UNIQUE_OACC_FORK as
targetm.have_oacc_fork () && targetm.have_oacc_join () both are false.
Afterward, it processes:
.chunk_max.3_10 = .GOACC_LOOP (CHUNKS, 1, 8, 1, -1, 0);
which then also gives an ICE.

The question is how to handle this properly. One way is to remove all asserts,
but that's somehow also not elegant. (There are more like for
expand_GOACC_REDUCTION, which are not triggered for this example.)

The following "fixes" the issue accordingly:

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 8efc77d986b..83c8ea5cc25 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2713,4 +2713,7 @@ expand_UNIQUE (internal_fn, gcall *stmt)
       gcc_unreachable ();

+    case IFN_UNIQUE_OACC_HEAD_MARK:
+    case IFN_UNIQUE_OACC_TAIL_MARK:
+      break;
     case IFN_UNIQUE_UNSPEC:
       if (targetm.have_unique ())
@@ -2736,6 +2739,4 @@ expand_UNIQUE (internal_fn, gcall *stmt)
            pattern = targetm.gen_oacc_join (target, data_dep, axis);
        }
-      else
-       gcc_unreachable ();
       break;
     }
@@ -2792,5 +2793,4 @@ static void
 expand_GOACC_LOOP (internal_fn, gcall *)
 {
-  gcc_unreachable ();
 }