[Bug c++/105861] New: OpenMP target construct not properly privatizing C++ member variables
cltang at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Jun 6 13:53:46 GMT 2022
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.
More information about the Gcc-bugs
mailing list