From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6431 invoked by alias); 4 Jan 2015 19:44:37 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6401 invoked by uid 89); 4 Jan 2015 19:44:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: DUB004-OMC4S10.hotmail.com Received: from dub004-omc4s10.hotmail.com (HELO DUB004-OMC4S10.hotmail.com) (157.55.2.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Sun, 04 Jan 2015 19:44:33 +0000 Received: from DUB118-W45 ([157.55.2.71]) by DUB004-OMC4S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 4 Jan 2015 11:44:30 -0800 X-TMN: [sUTZ5GihWIfp+s90V1zLb9rXPC1il6MU] Message-ID: From: Bernd Edlinger To: Jakub Jelinek , Mike Stump CC: "H.J. Lu" , "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C Date: Sun, 04 Jan 2015 19:44:00 -0000 In-Reply-To: <20150104191658.GK1667@tucnak.redhat.com> References: ,<3C12133C-DABF-40FA-94F7-9DB785F6E914@comcast.net>,,,<623A5348-6FC9-4F7B-A9BC-B2B098AF7D37@comcast.net>,<20150104191658.GK1667@tucnak.redhat.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg00096.txt.bz2 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 w= rote: >>> It is due to a race condition in tsan itself, it cannot decide which ac= cess was the >>> previous one and which was the second one, but our tsan tests are not m= eant as >>> a functional test of the tsan runtime library, they are only meant to t= est the GCC >>> instrumentation. >> >> Well, at least one test case that _is_ a functional test of the tsan run= time library isn=92t a bad idea. There are of course numerous functional tests, but they are all in LLVM's t= ree=20 at /compiler-rt/trunk/test/tsan > > The GCC instrumentation can be tested just by scanning the *.optimized du= mps > 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.=A0 I wonder if there is a test for that in the LLVM tree?=A0 Pro= bably they wouldn't consider that a BUG.=A0 I've looked deep in the implementation and= I saw, for every 8-byte word, there are 4 shadow words, each containing previ= ous 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_wri= te8, 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.=A0 As a matter of fact, the tsan runtime is just _incredibly_= fast, and catches errors, with a very high reliability.=A0 But it is racy by desi= gn. Bernd. > Jakub =20=09=09=20=09=20=20=20=09=09=20=20