[Bug middle-end/100144] New: [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"

[Bug middle-end/100144] New: [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144

            Bug ID: 100144
           Summary: [OpenMP] Data race with "omp parallel master taskloop
                    ...  shared(scalar)"
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

That's SOLLVE_VV's
https://github.com/SOLLVE/sollve_vv/blob/master/tests/5.0/parallel_master_taskloop/test_parallel_master_taskloop.c#L31

The code uses:

  int num_threads = -1;
...
#pragma omp parallel master taskloop num_threads(OMPVV_NUM_THREADS_HOST)
shared(x, y, z, num_threads)
  for (int i = 0; i < N; i++) {
    x[i] += y[i]*z[i];
    if (omp_get_thread_num() == 0) {
      num_threads = omp_get_num_threads();
    }
  }

Here: N = 1024, OMPVV_NUM_THREADS_HOST = 8 - and, hence,
"omp_get_thread_num() == 0" → 128 times true.

For num_threads:
* Result:  -1 (initial value) or 8
* Expected: always >= 0, in particular == 8


The race also occurs when the assignment is surrounded by 'omp atomic write' or
'omp critical' surrounding the assignment (occurs quickly) or around the whole
for-block (did not see it, but TSAN reports this).

[Bug middle-end/100144] [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This looks just like a bogus assumption in the testcase.
The taskloop directive says that the iterations are split into some tasks.  As
neither num_tasks nor graintsize clauses are specified, it is implementation
defined into how many tasks it is split.
But even when those would be specified, there is still no guarantee that the
master thread will execute any of those explicit threads, it can easily happen
that while the master thread creates the tasks other threads pick those tasks
already and there is no task left for the master thread.
The test should better use if (i == 0) num_threads = omp_get_num_threads();
then it has a guarantee that it will be executed exactly once.

[Bug middle-end/100144] [OpenMP] Data race with "omp parallel master taskloop ... shared(scalar)"

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Sollve_vv's testcase has been fixed:

Issue: https://github.com/SOLLVE/sollve_vv/issues/324
Patch test_parallel_master_taskloop.c:
https://github.com/SOLLVE/sollve_vv/pull/325
Patch test_parallel_master_taskloop_device.c:
https://github.com/SOLLVE/sollve_vv/pull/326