using dockers

https://github.com/LLNL/dataracebench/blob/master/micro-benchmarks/DRB170-flush-orig-no.c

This code is still too complex. It needs to be simplified much further.

There are too many things going on (nowait, several big loops )

The indentation is not aligned, hard to read. Please fix indentation.

Please give details about which exact variables are reported to have data races and only keep the code touch these variables.

Since the code has an intended race on the shared j, two threads / tasks might accidently access the same element of a via a[i][j] and a[i-1][j+100]. The chance for this to happen is probably quite low. I think, a@70:11 should be added nevertheless.

Examples:

Vivek Sarkar's IWOMP'19 paper

Ignacio's GPU data race student poster 19 summer

Need to use google scholar to find more

Is pireduction-orig-no really supposed to run 2 trillion times? Left the script running overnight and it's still working on it.

The next big things is to evaluate tools catching data races on GPUs. Even OpenMP CPU versions are perfectly fine, there are cases that the OpenMP compiler implementations introduce data races.

int argh --> int argc

Please specify which variables are reported to cause data races, in the comments
This is a general need for all NPB kernels you added. Please fix this for all.

The code is very strange. why are r1 and r2 private?

Many of them expose problems in the tools.

There is a race on res in line 28.

I would change to

res = omp_get_max_threads();

before the parallel region.

consider data-flow and control-flow information

miniAMR data races reported by OMPRacer

1 #pragma omp parallel default(shared) \
2 private(i, j, k, bp)
3 {
4 for (in = 0; in < sorted_index[num_refine+1]; in++)
5 {
6 bp = &blocks[sorted_list[in].n];
7 for (i = 1; i <= x_block_size; i++)
8 for (j = 1; j <= y_block_size; j++)
9 for (k = 1; k <= z_block_size; k++)
10 work[i][j][k] =
11 (bp->array[var][i-1][j ][k ] +
12 bp->array[var][i ][j-1][k ] +
13 bp->array[var][i ][j ][k-1] +
14 bp->array[var][i ][j ][k ] +
15 bp->array[var][i ][j ][k+1] +
16 bp->array[var][i ][j+1][k ] +
17 bp->array[var][i+1][j ][k ])/7.0;
18 for (i = 1; i <= x_block_size; i++)
19 for (j = 1; j <= y_block_size; j++)
20 for (k = 1; k <= z_block_size; k++)
21 bp->array[var][i][j][k] = work[i][j][k];
22 }
23 }

data races

• on loop index in at line 4: shared
• bp->array: bp is initialized from variable in used as index. Data races on in: bp may obtain the same blocks entry, in the end bp->array may be the same for different iterations.

iteration 0 and 1 can have conflicting writes to A[0]. But if they are scheduled to be run by the same thread, dynamic tools may miss this.

1 #pragma omp parallel for shared(A)
2 for(int i = 0; i < 10; i++) {
3 A[i] = i;
4 if (i == 1) { A[0] = 1; }
5 }

Credit: OMPRacer.

Other than the C-version, this code actually performs out of allocation access. I think, the indexes in the matrix assignment should be changed.

Do we have the latest detailed report like https://github.com/LLNL/dataracebench/wiki/Summary-report-Apr-2019 ?

https://github.com/LLNL/dataracebench/wiki/Regression-metrics shows good final metrics, but people may wonder the results for individual tests also.

https://github.com/LLNL/dataracebench/blob/master/micro-benchmarks/DRB169-nowait-orig-no.c

Please give details about the false positive about which pair of variable accesses in the comments.

If the second omp for loop does not contribute to the data races reported, please remove it.

int main(int argh, char* argv[])

• argh --> argc

Please fix other "argh" typos in your codes.

We should document how the tools we use are installed and configured.

We need to set up the CI Workflow to this repository so that contributors can continuously build and test the code to ensure that the commit doesn't introduce errors.

At least we should run some smoke test first.

This code is too complex. Please reduce it further. You don't need the same statements show up 15+ times in the loop. One or two may be sufficient.

Which variables cause the tools to report data races?

loop variables j and k are shared in this code, they may cause true posive data races.

only loop variable i immediately after "omp for" will be private by some implicit rule.

I am not sure this code is really data race free.

You can argue that the code has a race condition, but clearly no data race.

The code should also have a taskwait before the if, otherwise all tasks might execute after the printf.
I suggest to use #pragma omp taskyield in place of the empty task.

results in conflicts when switching branches after runing the benchmark

The code antidep1-var-yes.c not only has the anti dependency from the original code, but also introduced a data race on the inner loop variable j.
If you only want to have the intended anti-dependency in this code, there is a private(j) missing on the pragma omp for.

./check-data-races.sh --run runs to completion, albeit with an error: "jacobikernel-orig-no.c:130: undefined reference to `sqrt'".

But `./check-data-races.sh --helgrind just sits there forever. The file results/helgrind.csv seems to have all the benchmarks (as far as I can tell) but the script hangs with no response or output after the line "Saving results to results/helgrind.csv".

Running with --archer has the same effect.

This is on Ubuntu Linux 16.04.

for example, different versions of OpenMP, different languages.

The access a@29:7 accesses the private instance of a, this cannot race with the access a@25:5. The data race is in the reduction.

The new release should contain:

• Fortran tests
• OpenMP 5.0 tests
• New tests from benchmarks and literatures
• support customized file lists to define which programs to run
• updated dashboard showing the state-of-art of available tools

From OMPRacer paper:

1 int *A; int N;
2 load_from_input(A, &N);
3 #pragma omp parallel for shared(A)
4 for(int i = 0; i < N; i++) {
5 A[i] = i;
6 if (N > 10000) { A[0] = 1; }
7 }

Data races on A[0] happens only N is larger than a threshold.

I tried to use the command

./check-data-races.sh --tsan

And get an error message that Invalid tool name tsan

Please correct Ground Truth for the followings: Remember to correct it for all four tools excel sheet. Otherwise we will report wrong results.

• Archer Fortran
• Tsan Fortran
• ROMP Fortran
• Inspector

DRB131-taskdep4-orig-yes-omp45.f95
DRB134-taskdep5-orig-yes-omp45.f95
DRB142-acquirerelease-orig-yes-omp50.f95
DRB165-taskdep4-orig-yes-omp50.f95
DRB168-taskdep5-orig-yes-omp50.f95

Although it is not specified which section executes first and prints 1, the single thread clearly will print 1 first and then 2.

If the sections execute on different threads, they don't access the same memory, and therefore also no data race.

• Rebuild tools with LLVM10
• Rerun test programs using Archer and Tsan with the updated script and env var.
• Report any differences.

The variable volnew_o8 is shared and clang-tsan/11 correctly reports a data race:

==================
WARNING: ThreadSanitizer: data race (pid=236697)
  Write of size 8 at 0x7ffdfda476b0 by thread T7:
    #0 __drb050_MOD_foo1._omp_fn.0 DRB050-functionparameter-orig-no.f95:25 (DRB050-functionparameter-orig-no.f95.tsan-clang.out+0x4b3b5a)
    #1 __kmp_GOMP_microtask_wrapper(int*, int*, void (*)(void*), void*) <null> (libomp.so+0x87362)
    #2 __drb050_MOD_foo1 DRB050-functionparameter-orig-no.f95:26 (DRB050-functionparameter-orig-no.f95.tsan-clang.out+0x4b36ce)

  Previous write of size 8 at 0x7ffdfda476b0 by main thread:
    #0 __drb050_MOD_foo1._omp_fn.0 micro-benchmarks-fortran/DRB050-functionparameter-orig-no.f95:25 (DRB050-functionparameter-orig-no.f95.tsan-clang.out+0x4b3b5a)
    #1 __kmp_api_GOMP_parallel_40_alias <null> (libomp.so+0x8bb82)
    #2 __drb050_MOD_foo1 micro-benchmarks-fortran/DRB050-functionparameter-orig-no.f95:26 (DRB050-functionparameter-orig-no.f95.tsan-clang.out+0x4b36ce)

  Location is stack of main thread.

  Location is global '??' at 0x7ffdfda28000 ([stack]+0x00000001f6b0)

  Thread T7 (tid=236705, running) created by main thread at:
    #0 pthread_create tsan_interceptors_posix.cpp:966:199 (DRB050-functionparameter-orig-no.f95.tsan-clang.out+0x444deb)
    #1 __kmp_create_worker <null> (libomp.so+0x83086)

SUMMARY: ThreadSanitizer: data race DRB050-functionparameter-orig-no.f95:25 in __drb050_MOD_foo1._omp_fn.0
==================
ThreadSanitizer: reported 1 warnings

After making the variable private, the report is gone

Currently, this application has no memory access which would need any synchronization.
Further, this application has the additional issue of accessing uninitialized memory.

My suggestion is to change the code like:

int main()
{
  int i, j;
#pragma omp parallel for ordered(2)
  for (i = 0; i < 100; i++)
    for (j = 0; j < 100; j++)
    {
      a[i][j] = i + j;
#pragma omp ordered depend(sink:i-1,j) depend (sink:i,j-1)
      if (i>0 && j>0)
        a[i][j] = (a[i-1][j] + a[i][j-1] + a[i][j]) / 3;
      printf ("test i=%d j=%d\n",i,j);
#pragma omp ordered depend(source)
    }
  printf ("test a[99][99]=%d\n",a[99][99]);
  return 0;
}

The array is properly initialized. The assignment in the ordered region accesses the array fields, that are synchronized by the depend clauses. If the OpenMP implementation respects the depend clause on the ordered construct, the result should always be 196.

Without any failure, tools fail rate is not 1.0 (btw: how is this fail rate and not success rate?):

total test case is  172
compiler segmentation fault is  0
runtime segmentation fault is  0
compiler time out is  0
runtime time out is  0
tools fail rate is  0.9941860465116279
false positive is  0
true positive is  67
true negative is  89
false negative is  15

Also the last four number dont add up to 172.

When I change the reported data race in the cvs file for the first benchmark, the calculate metrics do not change.
I think for i in range(1,len(Ntruth)): in line 60 should be for i in range(len(Ntruth)):

Another minor issue:
Precision and Recall might be 0/0, which results in a python runtime error.

The file links to the md file of the c program list only.

Firstly, if the intention is to have undeferred tasks, the clause needs to be if(0).

In any case, you can simply remove the whole task region and will immediatlely see the data race on var.

Should the data race in DRB131-taskdep4-orig-omp45-yes.c be on lines 28 and 34?
The comment in the file says Data Race at y@36:19 and y@36:19 but line 36 contains no code.

NPB already exposes some new issues. I bet there are more in other OpenMP benchmarks.

for example , generate OpenMP programs from grammar rules

There are quite some unused variables in these new NPB kernels, please remove them.

One example: https://github.com/LLNL/dataracebench/edit/master/micro-benchmarks/DRB173-threadprivate3-orig-no.c
m and n are not used.

Please try to have high-quality of code extracted, minimal to reproduce the issues without compiler warnings (about unused variables) or errors.

Minimal means no unecessary statements which do not touch the variables reported to trigger data races.

Yaying has some experiences