Re: [PATCH, OpenMP, v2] Implement uses_allocators clause for target regions

[Chung-Lin Tang <cltang@codesourcery.com>]

On 2022/5/31 6:02 PM, Jakub Jelinek wrote:
> 5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just
>     look how it is handled for private too
> 
> 	Jakub

About private() for non-static members, is it really working right now?
A simple test:

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;
     }
}

This doesn't look quite right for private clause. I don't quite expect a zero-length mapping of this[:0],
nor reverting the gimple to use "this->a" for a private copy.

Chung-Lin