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

            Bug ID: 105861
           Summary: OpenMP target construct not properly privatizing C++
                    member variables
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cltang at gcc dot gnu.org
  Target Milestone: ---

struct C {
  omp_allocator_handle_t a;
  void foo (void) {
    #pragma omp target private (a)
     a = (omp_allocator_handle_t) 0;
  }
};

int main (void)
{
  C c;
  c.foo ();
  return 0;
}

After C++ front-end processing we get:

{
    omp_allocator_handle_t D.2823 [value-expr: ((struct C *) this)->a];
  #pragma omp target private(D.2823)
    {
      {
        <<cleanup_point <<< Unknown tree: expr_stmt
          (void) (D.2823 = 0) >>>>>;
      }
    }
}

The OMP field privatization seems to be doing something here.
However gimplify turns this into:

void C::foo (struct C * const this)
{
  omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];

  #pragma omp target num_teams(1) thread_limit(0) private(a) \
      map(alloc:MEM[(char *)this] [len: 0]) map(firstprivate:this [pointer
assign, bias: 0])
    {
      this->a = 0;
    }
}

Which is incorrect. Proper privatization should look something like this (which
works for omp parallel/task):

void C::foo (struct C * const this)
{
  omp_allocator_handle_t a [value-expr: ((struct C *) this)->a];

  #pragma omp parallel private(a)
    {
      a = 0;
    }
} 

Suspect that some where in gimplify, there's some insufficient handling of the
omp_disregard_value_expr langhook
under OMP_TARGET case. Creating issue here to track this.

Reply via email to