From patchwork Tue Jan 6 17:45:49 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 425759 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 9471C140082 for ; Wed, 7 Jan 2015 04:46:02 +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=t5AybZKtQtEiwSgiQf1Ed7MM9qWb0l0lxQC3sfMsRNXD12L3rKhfz wegPEs7Gp+y/nfa/Usl6AtI9zWxlb0HM2SqLXnPhSuL8w8XKscCiQpSW0TaTn+Yk CQIlhOoMVwdXzjPYZUSfHjhfbbtxU23DIQBGekWg4A+z6wIwzgoc+U= 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=0tYEVFrTUAj1x+mLW1JEeHEbDus=; b=qVcrO9HTKIpM1Hz37+aSnlXglfiT EdMjmZqFbmMBD4jv4GIpEMdxosqOM+USGNjWLV/nJluB51sEVqCiClTr7Mp5PkF4 20SJcSRcRz5BIRP8DdapC8zp/IBfyY7Lq6hzpUzl35MzPAjHi9systcnPCm9tPyk nH54ysJ/xkaTdSM= Received: (qmail 15078 invoked by alias); 6 Jan 2015 17:45:55 -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 15065 invoked by uid 89); 6 Jan 2015 17:45:54 -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-OMC4S12.hotmail.com Received: from dub004-omc4s12.hotmail.com (HELO DUB004-OMC4S12.hotmail.com) (157.55.2.87) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Tue, 06 Jan 2015 17:45:53 +0000 Received: from DUB118-W15 ([157.55.2.72]) by DUB004-OMC4S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 6 Jan 2015 09:45:49 -0800 X-TMN: [ILGBSRDh10PxQ0Eyqh3rP0awE4t9a3Dm] Message-ID: From: Bernd Edlinger To: Jakub Jelinek CC: Mike Stump , "H.J. Lu" , "gcc-patches@gcc.gnu.org" , Dmitry Vyukov Subject: RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C Date: Tue, 6 Jan 2015 18:45:49 +0100 In-Reply-To: <20150106091633.GF1667@tucnak.redhat.com> References: , <623A5348-6FC9-4F7B-A9BC-B2B098AF7D37@comcast.net>, <20150104191658.GK1667@tucnak.redhat.com>, , <8E43F8AA-96BA-47A3-A886-C058459B4108@comcast.net>, , , , , , <20150106091633.GF1667@tucnak.redhat.com> MIME-Version: 1.0 ---------------------------------------- > Date: Tue, 6 Jan 2015 10:16:33 +0100 > From: jakub@redhat.com > To: bernd.edlinger@hotmail.de > CC: mikestump@comcast.net; hjl.tools@gmail.com; gcc-patches@gcc.gnu.org; dvyukov@google.com > Subject: Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C > > 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 I tried your suggestion now, and it seems to work. (on a  4-way core AMD64 laptop) Would you prefer this over adding a sleep in Thread1, which I posted previously? 2015-01-06  Bernd Edlinger          * g++.dg/tsan/aligned_vs_unaligned_race.C: Fixed sporadic failure. Thanks, Bernd. Index: aligned_vs_unaligned_race.C =================================================================== --- aligned_vs_unaligned_race.C    (revision 219198) +++ aligned_vs_unaligned_race.C    (working copy) @@ -1,5 +1,7 @@  /* { dg-shouldfail "tsan" } */ +/* { dg-additional-options "-pthread" } */  #include +#include  #include  #include   @@ -19,6 +21,12 @@ void *Thread2(void *x) {  }    int main() { +  /* Run this test on a single CPU, to make it somewhat easier for tsan to +     detect the race condition.  */ +  cpu_set_t s; +  CPU_ZERO(&s); +  CPU_SET(0, &s); +  pthread_setaffinity_np(pthread_self(), sizeof(s), &s);    pthread_t t[2];    pthread_create(&t[0], NULL, Thread1, NULL);    pthread_create(&t[1], NULL, Thread2, NULL);