From patchwork Sun Jan 4 22:19:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 425212 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id B6699140082 for ; Mon, 5 Jan 2015 09:20:08 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:from:to:cc:subject:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; q=dns; s= default; b=ZWJE+d7wJ3TNfio2FmXySjuiL4Tzyw1vdQW2Dt+DwjwB6uKlvDqbE j+Bq0sOmUOv0vs++yoVW1h2vBU0tslyuQRyYj8KdsXmORxEczVzQLinbj8d03i24 WifsZJyLur1SO2fBauj1T3R4mGow4UXWUaqceQdjTzAParhjK6snNg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:from:to:cc:subject:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; s=default; bh=mZ2jCrW1DbUIpMZvzVgnPam+io8=; b=eNakLaiigGegi+MkpW+BGj3+sUz/ HUVoTyypopWEH+gulrwILwL7MbNWmnoHuZxed3HdofepS+2mJQdeTfbeGdX6NBbB vj1ofmwUscjuPxUfXLZo8i/aEputFmVm7N9W9qfUB6bWBWGt+xHMug4eqQCLVQxe d8KPcfe35ziCzrU= Received: (qmail 4019 invoked by alias); 4 Jan 2015 22:20:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 3997 invoked by uid 89); 4 Jan 2015 22:20:01 -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-OMC4S20.hotmail.com Received: from dub004-omc4s20.hotmail.com (HELO DUB004-OMC4S20.hotmail.com) (157.55.2.95) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Sun, 04 Jan 2015 22:19:59 +0000 Received: from DUB118-W3 ([157.55.2.71]) by DUB004-OMC4S20.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 4 Jan 2015 14:19:56 -0800 X-TMN: [7fj/eJkp6yIlGtcd3nJkrAJjFO5OsOTR] Message-ID: From: Bernd Edlinger To: Mike Stump , Dmitry Vyukov CC: Jakub Jelinek , "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C Date: Sun, 4 Jan 2015 23:19:55 +0100 In-Reply-To: References: , <3C12133C-DABF-40FA-94F7-9DB785F6E914@comcast.net>, , <18CD1660-7BFC-4E97-85E2-B523365E8E86@comcast.net>, , MIME-Version: 1.0 On Sun, 4 Jan 2015 13:57:38, Mike Stump wrote: > > On Jan 4, 2015, at 1:48 PM, Bernd Edlinger wrote: >> I would need a way to link the test case two helper functions, that are not compiled with -fsanitize=thread > > /* { dg-additional-sources “tsan-helper.c" } */ > > might be one step forward to do that. I don’t know off hand about the options. I think you may be able to specify unique options per file. > >> I tried, it and it works 10.000 times without one failure. > > So, statistically knowing it works in practice is nice. However, the standard is, does is work by design? I’ll let you comment on that. The sync approach I designed to work in any case, no matter the complexity, by design. I’d assume that you’ve engineered it to work by design. IMO Yes, but Dmitry may know better. Tsan does not acquire a mutex _before_ it detects a race. And race conditions that happen exactly synchronous may be invisible. If we use some hidden mechanism to ensure that certain events happen in a certain sequence, that would make a big difference. It would work much better than sleep(), we only need sleep if we need to see the "as if synchronized via sleep" diagnostic. I see now, that our tsan tests are almost verbatim copies of the LLVM test suite. They _do_ have problems with the stability of positive tests, especially under stress, I see all positive tests are called by a "deflake" tool, that exercises the test 10 times, until it eventually succeeds. I see one other test (which we apparently do not have here), was changed recently from sleep(2) to sleep(4) [Tsan] Fix the atomic_race.cc test to pass on systems with high loads Differential Revision: http://reviews.llvm.org/D6478 Thanks Bernd. --- compiler-rt/trunk/test/tsan/atomic_race.cc 2014/05/30 14:08:51 209898 +++ compiler-rt/trunk/test/tsan/atomic_race.cc 2014/12/02 15:04:39 223122 @@ -36,7 +36,7 @@ for (int i = 0; i < kTestCount; i++) { Test(i, &atomics[i], false); } - sleep(2); + sleep(4); for (int i = 0; i < kTestCount; i++) { fprintf(stderr, "Test %d reverse\n", i); Test(i, &atomics[kTestCount + i], false);