[Bug middle-end/91216] New: [9/10 Regression] OpenMP ICE starting with r265930

[jakub at gcc dot gnu.org]

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

            Bug ID: 91216
           Summary: [9/10 Regression] OpenMP ICE starting with r265930
           Product: gcc
           Version: 9.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int r;

void
foo (int *a)
{
  int i;
  #pragma omp for reduction(+:r)
  for (i = 0; i < 64; i++)
    a[i] = i;
  #pragma omp for private (r)
  for (i = 0; i < 64; i++)
    {
      r = 0;
      #pragma omp parallel shared(r)
      #pragma omp master
      r = r + 1;
    }
}

ICEs with -fopenmp starting with r265930, most likely due to the         be
passing an address in this case?  Should we simply assert
         this to be false, or should we have a cleanup pass that removes
         these from the list of mappings?  */
-      if (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
+      if (is_global_var (maybe_lookup_decl_in_outer_ctx (decl, shared_ctx)))
        return true;

       /* For variables with DECL_HAS_VALUE_EXPR_P set, we cannot tell
omp-low.c hunk.
r is a global decl, initially not TREE_ADDRESSABLE and turned into
TREE_ADDRESSABLE during the reduction handling of the first worksharing loop,
which means that the scaning of the parallel clauses and later lowering
disagree on whether shared(r) is passed by reference or through copy-in/out.