https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114445
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[OpenMP] indirect - |[OpenMP] indirect - race
|potential race when |when creating
|creating reverse-offload |reverse-offload hash,
|hash |causing aborts
CC| |ams at gcc dot gnu.org,
| |kcy at codesourcery dot com
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Another kind of race happens with MI300:
libgomp/config/accel/target-indirect.c has:
-------
build_indirect_map (void)
…
indirect_htab = htab_create (num_ind_funcs);
GOMP_target_map_indirect_ptr (void *ptr)
…
assert (indirect_htab);
–
-------
And this assert triggers …
… as there is a race in libgomp/config/gcn/team.c:
----------------------
gomp_gcn_enter_kernel (void)
{
int threadid = __builtin_gcn_dim_pos (1);
if (threadid == 0)
{
int teamid = __builtin_gcn_dim_pos(0); /* Initialize indirect function
support. */
if (teamid == 0)
build_indirect_map ();
…
asm ("s_barrier" ::: "memory");
return; /* Return to kernel. */
}
else
{
asm ("s_barrier" ::: "memory");
gomp_thread_start (gcn_thrs ()[0].thread_pool);
----------------------
The problem is that "s_barrier" does not synchronize between teams. Thus, if
team == 2 has finished initializing itself, it starts – while team == 0 might
either not even have started to initialize the reverse table or it is
incomplete.
This causes libgomp.c-c++-common/declare-target-indirect-2.c to fail rather
reliably on MI300.
