http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302
--- Comment #3 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Joost VandeVondele from comment #2) > (In reply to Kostya Serebryany from comment #1) > > This isn't expected to happen and so we did not write a better warning > > message. > > We may be able to fix it, but the underlying problem is in your tests: > > it has a race that tsan is trying to report and which is suppressed > > (probably because a similar races was reported before). > > > > How many race reports do you see before tsan crashes? > > Did you suppress any of those? > > yes, I have a suppression in place to workaround PR59194. As it is an atomic > update in a hot loop, it will be triggered millions of times. Suppressing a race that happens so many times is no good. Even if we fix the crash above (which I'd prefer not to; instead we should emit a more descriptive message and die; we'll do that) tsan will remain very slow. The right solution is of course to fix the code to not have that race. The next good solution is to annotate the function with __attribute__((no_sanitize_thread)) -- but I don't know if fortran has anything like this. The next somewhat good solution is to blacklist the function (https://code.google.com/p/thread-sanitizer/wiki/Flags?ts=1385538776&updated=Flags#Blacklist_Format) but that is not supported by GCC and will have to be implemented first.
