The documentation for the Valgrind thread error detection tool Helgrind, found here
warns that, if you use GCC to compile your OpenMP code, GCC's OpenMP runtime library (libgomp.so) will cause a chaos of false positive reports of data races, because of its use of atomic machine instructions and Linux futex system calls instead of POSIX pthreads primitives. It tells you that you can solve this problem, however, by recompiling GCC with the --disable-linux-futex configuration option.
So I tried this. I compiled and installed to a local directory (~/GCC_Valgrind/gcc_install) a new GCC version 4.7.0 (the latest release as of this writing) with the --disable-linux-futex configuration option. I then created a small OpenMP test program (test1.c) that has no visible data races:
/* test1.c */
#include <omp.h>
#include <stdio.h>
#include <stdlib.h>
#define NUM_THREADS 2
int a[NUM_THREADS];
int main(void) {
int i;
#pragma omp parallel num_threads(NUM_THREADS)
{
int tid = omp_get_thread_num();
a[tid] = tid + 1;
}
for (i = 0; i < NUM_THREADS; i++)
printf("%d ", a[i]);
printf("\n");
return EXIT_SUCCESS;
}
I compiled this program as follows
~/GCC_Valgrind/gcc_install/bin/gcc -Wall -fopenmp -static -L~/GCC_Valgrind/gcc_install/lib64 -L~/GCC_Valgrind/gcc_install/lib -o test1 test1.c
However, I got 30 false positive data race reports!--all occurring in libgomp code. I then compiled test1.c without the -static flag, and ran Helgrind on it again. This time, I got only 9 false positive data race reports, but that is still too many--and, without the -static flag, I cannot trace the supposed race in the libgomp code.
Has anybody found a way to reduce, if not eliminate, the number of false positive data race reports from Helgrind applied to an OpenMP program compiled with GCC? Thanks!
-Wl,-rpath,/path/to/recompiled/lib. – Barbeytidas private? – Dogvanetidis supposed to be private, since it is declared inside the parallel section. Anyway, the syntax would have been#pragma omp parallel private(tid). – Dogvane