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
