Helgrind (Valgrind) and OpenMP (C): avoiding false positives?

Sorry to put this in as an answer since it's more of a comment, but it's too long to fit in as a comment, so here goes:

From the site you referenced.

Runtime support library for GNU OpenMP (part of GCC), at least for GCC versions 4.2 and 4.3. The GNU OpenMP runtime library (libgomp.so) constructs its own synchronisation primitives using combinations of atomic memory instructions and the futex syscall, which causes total chaos since in Helgrind since it cannot "see" those.

Fortunately, this can be solved using a configuration-time option (for GCC). Rebuild GCC from source, and configure using --disable-linux-futex. This makes libgomp.so use the standard POSIX threading primitives instead. Note that this was tested using GCC 4.2.3 and has not been re-tested using more recent GCC versions. We would appreciate hearing about any successes or failures with more recent versions.

as you mentioned in your post, this has to do with libgomp.so, but that's a shared object, so I don't see how you can pass the -static flag and still use that library. Am I just misinformed?

Steps which will make it work:

1. Recompile gcc (including libgomp) using --disable-linux-futex
2. Make sure you use the futex free gcc when compiling your program.
3. Make sure the system will load the futex free libgomp when executing your program (the library is usually in GCC-OBJ-DIR/PLATFORM/libgomp/.libs). For example by setting the LD_LIBRARY_PATH environment variable:

export LD_LIBRARY_PATH=~/gcc-4.8.1-nofutex/x86_64-unknown-linux-gnu/libgomp/.libs:

Please also note, that if omp_set_lock is used in the code the omp.h path must be substituted because of different lock struct size. See https://xrunhprof.wordpress.com/2018/08/27/tsan-with-openmp/