https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114445
Bug ID: 114445
Summary: [OpenMP] indirect - potential race when creating
reverse-offload hash
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
It looks as if when starting two kernels very quickly after another as in
#pragma omp target nowait
...
#pragma omp target
...
Two device threads might concurrently create the hash in
libgomp/config/accel/target-indirect.c's build_indirect_map
if (!indirect_htab)
{
/* Count the number of entries in the NULL-terminated address map. */
for (map_entry = GOMP_INDIRECT_ADDR_MAP; *map_entry;
map_entry += 2, num_ind_funcs++);
indirect_htab = htab_create (num_ind_funcs);
The issue only occurs if the assignment of the allocated memory done in the
first thread occurs after the second kernel has checked for indirect_htab ==
NULL, which seems to be rather unlikely to happen in the real world, but IMHO
cannot be ruled out.
Thus, I was wondering (see email) whether a tmp variable + CAS should be used
for indirect_htab; if the swap failed, the memory could just be freed as
another process was faster - and has also completed by then the creation of the
htab.
See also
r14-9629-g637e76b90e8b045c5e25206a41e3be55deace8d5
openmp: Change to using a hashtab to lookup offload target addresses for
indirect function calls
and review email at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647755.html
