This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Jakub Jelinek <jakub at redhat dot com>, Mike Stump <mikestump at comcast dot net>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 4 Jan 2015 20:44:30 +0100
- Subject: RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W421A4A9D8D09CBAF5103DAE45A0 at phx dot gbl>,<3C12133C-DABF-40FA-94F7-9DB785F6E914 at comcast dot net>,<DUB118-W292D09896C48BED7B29B14E45A0 at phx dot gbl>,<DUB118-W8F5E63DE36A8DB2DA1DF6E45B0 at phx dot gbl>,<623A5348-6FC9-4F7B-A9BC-B2B098AF7D37 at comcast dot net>,<20150104191658 dot GK1667 at tucnak dot redhat dot com>
Hi,
On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
>
> On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
>> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>> It is due to a race condition in tsan itself, it cannot decide which access was the
>>> previous one and which was the second one, but our tsan tests are not meant as
>>> a functional test of the tsan runtime library, they are only meant to test the GCC
>>> instrumentation.
>>
>> Well, at least one test case that _is_ a functional test of the tsan runtime library isn’t a bad idea.
There are of course numerous functional tests, but they are all in LLVM's tree
at /compiler-rt/trunk/test/tsan
>
> The GCC instrumentation can be tested just by scanning the *.optimized dumps
> or assembly. And perhaps the runtime test just be hidden by some special
> environment variable that the user acks he doesn't main spurious FAILs.
>
I never had suspected the sleep calls to play such an important role, If I did, I would
have smuggled one in before checking in....
That's surely due to that there was no comment anywhere mentioning that race
condition. I wonder if there is a test for that in the LLVM tree? Probably they
wouldn't consider that a BUG. I've looked deep in the implementation and I
saw, for every 8-byte word, there are 4 shadow words, each containing previous
accesses with call stack, and the __tsan_write8 functions just dont lock
a mutex because of performance reasons, if the application does not have
a race conditions tsan does not have a race either, if the application has a
race condition, there is a certain chance that both threads call __tsan_write8,
both look at the same shadow word, see nothing, and both write their
callstack in the same shadow cell. But tsan still gets at least 90% chance
to spot that. As a matter of fact, the tsan runtime is just _incredibly_ fast,
and catches errors, with a very high reliability. But it is racy by design.
Bernd.
> Jakub