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: Jakub Jelinek <jakub at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Mike Stump <mikestump at comcast dot net>, "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>, Dmitry Vyukov <dvyukov at google dot com>
- Date: Tue, 6 Jan 2015 10:16:33 +0100
- Subject: Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W8F5E63DE36A8DB2DA1DF6E45B0 at phx dot gbl> <623A5348-6FC9-4F7B-A9BC-B2B098AF7D37 at comcast dot net> <20150104191658 dot GK1667 at tucnak dot redhat dot com> <DUB118-W450ACE7162969EFB27F817E45B0 at phx dot gbl> <8E43F8AA-96BA-47A3-A886-C058459B4108 at comcast dot net> <DUB118-W286F157F7B8B1EE05ED51FE4580 at phx dot gbl> <E67B07D7-6ABA-48C1-B58B-B804144D91C2 at comcast dot net> <D86529BC-DB94-481A-AE60-913D7E2B8D7F at comcast dot net> <DUB118-W1E901D082BACEDE02A5E8E4590 at phx dot gbl> <DUB118-W468072AA78C7E7CD1DCF6BE4590 at phx dot gbl>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
> Hi Mike,
>
> after some hours of sleep I realized that your step function can do something very interesting,
> (which you already requested previously):
>
> That is: create a race condition that is _always_ at 100% missed by tsan:
>
> cat lib.c
> /* { dg-do compile } */
> /* { dg-options "-O2 -fno-sanitize=all" } */
>
> static volatile int serial = 0;
>
> void step (int i)
> {
> while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
> __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
> }
Such busy waiting is not very CPU time friendly in the testsuite, especially
if you have just a single HW thread.
If libtsan is not fixed not to be so racy, perhaps instead of all the sleeps
we could arrange (on x86_64-linux, which is the only target supporting tsan
right now) to make sure the thread runs on the same core/hw thread as the
initial thread using pthread_[gs]etaffinity_np/pthread_attr_setaffinity_np ?
Does tsan then always report the races when the threads can't run
concurrently?
Jakub