From patchwork Mon Feb 15 11:29:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 582847 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 4553A1402D9 for ; Mon, 15 Feb 2016 22:29:48 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=TK87kkou; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; q=dns; s=default; b=gz1rYgOKnybjwZvI P9pnrebkTk9H06icRQciRhMqBEz8qlDMQwv6Nh/S1hno6FHJHOYYLI6xQKKKRRJM RUoq0y/QrT7wxGQTVaooExOEaKvinKpp9dYVC76d5eVTSI7Qr6uSMZcsPuWKkxXV HYxikvA2t1BwSMD9zl15cdo1j5M= 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:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=default; bh=ud6HWqy0KZhhMSPdzw9wUu ked8A=; b=TK87kkouVdm7tmicHfQErJhG5yjhycnNlsvdbHMZ97ydbJZCkx2vGH ZqtftcqG62ocQf+d8Bk0HbZsbQfm/4dC44Lq7HBkACbhSeQH2LGLJ+bfcEfhBaKC JMSYiJca0CM1Jam2RU7kMumCu22inksgkLwI+TQtC4sZEhrVaGeU4= Received: (qmail 74316 invoked by alias); 15 Feb 2016 11:29:39 -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 74297 invoked by uid 89); 15 Feb 2016 11:29:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=HX-MS-Has-Attach:yes, H*c:HHH, claim, person X-HELO: DUB004-OMC4S14.hotmail.com Received: from dub004-omc4s14.hotmail.com (HELO DUB004-OMC4S14.hotmail.com) (157.55.2.89) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Mon, 15 Feb 2016 11:29:36 +0000 Received: from emea01-am1-obe.outbound.protection.outlook.com ([157.55.2.72]) by DUB004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 15 Feb 2016 03:29:32 -0800 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com (10.162.26.12) by HE1PR07MB0906.eurprd07.prod.outlook.com (10.162.26.13) with Microsoft SMTP Server (TLS) id 15.1.409.15; Mon, 15 Feb 2016 11:29:31 +0000 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) by HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) with mapi id 15.01.0409.017; Mon, 15 Feb 2016 11:29:30 +0000 From: Bernd Edlinger To: Dmitry Vyukov , Tom de Vries CC: "gcc-patches@gcc.gnu.org" , Jakub Jelinek , Dodji Seketeli , Kostya Serebryany , "thread-sanitizer@googlegroups.com" Subject: Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite Date: Mon, 15 Feb 2016 11:29:30 +0000 Message-ID: References: <56C1AC43.4070309@mentor.com>, In-Reply-To: authentication-results: gcc.gnu.org; dkim=none (message not signed) header.d=none; gcc.gnu.org; dmarc=none action=none header.from=hotmail.de; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [RxPanbHb/wudTUN0gnqAOUvM9LNwAv+7] x-microsoft-exchange-diagnostics: 1; HE1PR07MB0906; 23:quV4CXjiM1agcJmXmhClQo4/eMaKfA9mdCPxOeKkmqMF3l/CrBFNnS07qMSBWaFcEO6Lub/cL0jTMWJWZkzczcQFQjd9gvECylXTOA+H1VkixzQ+O/i/AUJay8QtQtzy3aOy+qkp00/xVXA5grtu22rmV3+AkOWiEYQ756MqnQ4jGhv7z+cZGm0NvDiXrOzS+k6oHrfE7tS6BZiGsn9PJA==; 5:ecRW8nQrAZ7PDodU4epdsLi+8iCQz02/kr4WpVcxWjrUDKJmEr+5JInjGnplInY6OsSXmtnUxDnQRtLY+LJyVqCG0JtVxz9+3A0qsjxbvKnp0Y/lBZvw17/PvJ4fUjd8y8d76iggOJx9EGz+A/XNmw==; 24:5A0D6SwcHjNeHp0dVqt6bVpKIixXh/FbmzhyupixPm9LbzYSaS1nx4DDD62iv0ndTuAt0S3WApXKK2Kvil9ZcA0MewyaVZt4/CkkjfkNPPk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0906; x-ms-office365-filtering-correlation-id: ea196d90-ad52-4da3-ddea-08d335fb458f x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(102415293)(102615271)(82015046); SRVR:HE1PR07MB0906; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0906; x-forefront-prvs: 08534B37A7 x-forefront-antispam-report: SFV:NSPM; SFS:(7070004)(98900003); DIR:OUT; SFP:1901; SCL:1; SRVR:HE1PR07MB0906; H:HE1PR07MB0905.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sct-15-1-409-10-msonline-outlook-d6129.templateTenant X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2016 11:29:30.7616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0906 On 15/02/16 08:18, Dmitry Vyukov wrote: > llvm tsan tests contain test.h file (probably what's called > test_barrier.h in gcc), you can put the macro there. test.h should > already be included into all tests. Hmm.. as the person who introduced test_barrer.h (well before llvm had a test.h ;) I must say, that although if gcc was first here, we will probably change that to match llvm's implementation for gcc-7. I would not like to add more differences here without a very good reason. I'd say, if Dmitry sees a reason to improve the error handling in test.h, that is a good thing, and should go into llvm's tree first. And independently of that I am looking at using llvm's test.h framework instead of gcc's test_barrier.h for gcc-7 soon. On 15/02/16 11:56, Tom de Vries wrote: > On Mon, Feb 15, 2016 at 11:45 AM, Tom de Vries wrote: >> >> I've tried to be as clear as possible in the RFC submission that I'm not >> certain about the cause of the failure, and that the patch is proposing a >> fix that would make that guessed failure cause explicit. >> >>> Sure pthread_create can fail, as malloc and mmap. >>> But if that is the reason for the failure it would happen >>> just randomly, everywhere. >>> >>> Why do you think that only this test case shows the problem? >>> >> >> As I explained in the RFC submission, my reasoning there was that the test >> is one of the very few test cases that tests the result of pthread_create >> and then returns 0, which causes the failure in combination with >> dg-shouldfail. >> >> But thinking about it some more, even if pthread_create would fail, causing >> the testcase to fail in execution, allowing the execution test to pass due >> to dg-shouldfail, presumably the dg-output test would still fail in that >> case, so my reasoning was not sound. >> >> So I suppose you're right, indeed the pthread_create fail hypothesis is not >> the most logical one. >> >> Still, the patch is an improvement irrespective of the PR that inspired it, >> and perhaps a lot more library calls should be checked for errors that just >> pthread_create. >> >>> I think Dmitry's comment may be right on the point. >> >> >> If someone proposes that as a patch for the testcase, great. I'm more that >> willing to test that in my setup to be able to claim 'bootstrapped and >> reg-tested on x86_64' in the submission. >> No problem. PR65400 was a GCC wrong code bug, so it makes no sense to have the same test in llvm's tree, thus we are free to fix it on our own, as we like. Here is a patch that puts each value on it's own 8-byte aligned memory location. From my experience with tsan tests, sharing shadow memory slots between v and q or o is the most likely explanation for the occasional inability to spot the race condition on v, thus the test case fails, because the return code is 0, and the expected output is not found. Boot-strapped/regression tested on x86_64-linux-gnu. OK for trunk? Thanks Bernd. 2016-02-15 Bernd Edlinger * c-c++-common/tsan/pr65400-1.c (v, q, o): Make 8-byte aligned. --- gcc/testsuite/c-c++-common/tsan/pr65400-1.c.jj 2015-03-19 08:53:38.000000000 +0100 +++ gcc/testsuite/c-c++-common/tsan/pr65400-1.c 2016-02-15 11:09:18.852320827 +0100 @@ -7,9 +7,9 @@ #include "tsan_barrier.h" static pthread_barrier_t barrier; -int v; -int q; -int o; +int v __attribute__((aligned(8))); +int q __attribute__((aligned(8))); +int o __attribute__((aligned(8))); extern void baz4 (int *); __attribute__((noinline, noclone)) int