[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Last reconfirmed||2024-02-29 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #54 from Eric Gallager --- Confirmed that providing an instrumented libgomp would be worthwhile.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #50 from Roland Schulz roland at rschulz dot eu --- I must say I don't know how the internals work. But I assume that reductions are implemented in libgomp (I know they are in iomp). Thus for any code which uses OpenMP reduce statements, libgomp would touch user data.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #51 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Roland Schulz from comment #50) I must say I don't know how the internals work. But I assume that reductions are implemented in libgomp (I know they are in iomp). Thus for any code which uses OpenMP reduce statements, libgomp would touch user data. Your assumption is wrong, reductions are not handled in libgomp, but in the code emitted by the compiler.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #52 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #51) Your assumption is wrong, reductions are not handled in libgomp, but in the code emitted by the compiler. does this imply that the combination of -fsanitize=thread and a libgomp as obtained with --disable-linux-futex is indeed a 'proper' solution for this PR, or do you think that building two libraries such as suggested in comment #42 would be best ?
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #53 from Dmitry Vyukov dvyukov at google dot com --- If we instrument libgomp with tsan, this can introduce lots of extraneous synchronization which is useful only for verification of libgomp itself, but harmful for libgomp users (as it will lead to false positives). What can be useful (but not top priority if nobody complains) is to insert some manual annotations for tsan into libgomp. I don't know enough about libgomp internals and have not used libgomp+tsan, so don't know what exactly they must do. But potentially they can do: 1. Tell tsan about accesses to user memory. I.e. if libgomp still accesses some user memory in some cases, then can tell tsan about that. 2. Tell tsan about precise synchronization model for user. E.g. I suspect that interactions with scheduler in parallel for construct synchronize all user threads (if the scheduler calls pthread_mutex_lock/unlock); this synchronization can lead to false positives in user programs. We can suppress that synchronization and instead tell tsan what is the documented synchronization guarantees for user. 3. Improve reports.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #47 from Roland Schulz roland at rschulz dot eu --- Using 4.9 and --disable-linux-futex I don't get any false positives. Thus the problem I saw with 4.8.2 is indeed fixed with 4.9. Thanks! What is the advantage of a TSAN instrumented libgomp over one with --disable-linux-futex?
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #48 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Roland Schulz from comment #47) What is the advantage of a TSAN instrumented libgomp over one with --disable-linux-futex? I would be happy to know that '--disable-linux-futex' is a suitable approach, as that would be rather practical. However, my first idea would be that, since libgomp is not sanitized, not all races in 'user land' would be detected. I'm just guessing ...
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #49 from Dmitry Vyukov dvyukov at google dot com --- However, my first idea would be that, since libgomp is not sanitized, not all races in 'user land' would be detected. I'm just guessing ... If libgomp does not access user data (which I suspect it does not generally do), then un-instrumented libgomp can only lead to false positives due to missed synchronization in libgomp. The missed synchronization can come mostly from atomic operations, because tsan intercepts pthread_mutex and other library functions.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #46 from Dmitry Vyukov dvyukov at google dot com --- Roland, why do you think that what you see is false positives? I think these are real, potentially harmful, races. Please test with gcc 4.9, and file bugs if you still see any races.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Roland Schulz roland at rschulz dot eu changed: What|Removed |Added CC||roland at rschulz dot eu --- Comment #44 from Roland Schulz roland at rschulz dot eu --- If I run tsan on our code with libgomp compiled with --disable-linux-futex, I only see false positives for omp-atomic constructs. Everything else seems fine. If I compile libgomp with tsan and without --disable-linux-futex I get a lot of false positives. And if I compile libgomp with both tsan and --disable-linux-futex, I get also the false positives for omp-atomic. I used gcc 4.8.2. For those who reported success with compiling libgomp with tsan: - Do you also use --disable-linux-futex or did you only use -fsanitize=thread? - Did you test with code using #pragma omp atomic update? Is there a way to compile libgomp to not get false positives for omp-atomic?
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #45 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Roland Schulz from comment #44) Is there a way to compile libgomp to not get false positives for omp-atomic? yes, this is fixed in gcc for 4.9.0 see PR59194 or r206572 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194#c11 I believe that some of the other aspects you're seeing with 4.8.2 might also be fixed in 4.9 (not sure).
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #43 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Emil Styrke from comment #42) Anyway, after manually fixing up the install it seems to work alright. If this looks like a reasonable way forward, I'd be happy to improve the patch after feedback or leave this embryo in the hands of someone more knowledgeable. I would welcome such a solution very much. From looking at the patch, it seems a relatively small amount of work for a significant benefit. I hope you get some feedbackhelp from libgomp/sanitizer experts.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Emil Styrke emil.styrke at gmail dot com changed: What|Removed |Added CC||emil.styrke at gmail dot com --- Comment #42 from Emil Styrke emil.styrke at gmail dot com --- Created attachment 31905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31905action=edit Patch idea (In reply to Joost VandeVondele from comment #40) I'm updating the summary for this bug. It is my impression that tsan omp now work well together, but in order for this to be useful, a tsan instrumented libgomp needs to be linked in. In my opinion, it would be great if gcc would build to versions of the runtime library (one standard, one tsan instrumented) and link the tsan instrumented libgomp as needed. As a side effect, it will provide good checking for the libgomp library. I also believe this is a more sustainable approach than writing wrappers for all omp functionality. I have made a try to create a patch for this, just to get the ball rolling. However, my autotools knowledge is a bit thin and my experience with the GCC codebase even thinner, so I didn't get all the way. The idea is to create a tsan-instrumented libgomp as libgomp_tsan.so and change the libgomp.spec to select that library instead if -fsanitize=thread is used. Issues I didn't manage to sort out: * Correctly detecting if tsan support is available (as evident by the commented-out logic in the patch). * The vpath magic for finding the files in config/ breaks for the new target because explicit targets are created for each source file. I hacked around this by hard-coding the paths for Linux, but obviously this is ugly. * It seems the multilib support broke with this patch (I get the resulting library and spec file in lib/ instead of lib32/ and lib64/), but maybe I just handled the build scripts wrong... * There are no test cases... Anyway, after manually fixing up the install it seems to work alright. If this looks like a reasonable way forward, I'd be happy to improve the patch after feedback or leave this embryo in the hands of someone more knowledgeable.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #41 from Dmitry Vyukov dvyukov at google dot com --- Similar problem with libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|TSAN: Fortran/OMP yields|TSAN: provide a TSAN |false positives |instrumented libgomp --- Comment #40 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:11:17 UTC --- I'm updating the summary for this bug. It is my impression that tsan omp now work well together, but in order for this to be useful, a tsan instrumented libgomp needs to be linked in. In my opinion, it would be great if gcc would build to versions of the runtime library (one standard, one tsan instrumented) and link the tsan instrumented libgomp as needed. As a side effect, it will provide good checking for the libgomp library. I also believe this is a more sustainable approach than writing wrappers for all omp functionality.
