From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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:00 -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 Content-Type: multipart/mixed; boundary="_002_HE1PR07MB0905578859D3EC1C8AFFD5CFE4AC0HE1PR07MB0905eurp_" 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 X-SW-Source: 2016-02/txt/msg00976.txt.bz2 --_002_HE1PR07MB0905578859D3EC1C8AFFD5CFE4AC0HE1PR07MB0905eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 3002 On 15/02/16 08:18, Dmitry Vyukov wrote:=20 > 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 te= st.h ;) I must say, that although if gcc was first here, we will probably change t= hat 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, t= hat 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 ins= tead 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 w= rote: >> >> 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 te= st >> 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, caus= ing >> the testcase to fail in execution, allowing the execution test to pass d= ue >> 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 j= ust >> 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 th= at >> 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.= --_002_HE1PR07MB0905578859D3EC1C8AFFD5CFE4AC0HE1PR07MB0905eurp_ Content-Type: text/x-patch; name="patch-pr68580.diff" Content-Description: patch-pr68580.diff Content-Disposition: attachment; filename="patch-pr68580.diff"; size=575; creation-date="Mon, 15 Feb 2016 11:28:11 GMT"; modification-date="Mon, 15 Feb 2016 11:28:11 GMT" Content-Transfer-Encoding: base64 Content-length: 781 MjAxNi0wMi0xNSAgQmVybmQgRWRsaW5nZXIgIDxiZXJuZC5lZGxpbmdlckBo b3RtYWlsLmRlPgoKCSogYy1jKystY29tbW9uL3RzYW4vcHI2NTQwMC0xLmMg KHYsIHEsIG8pOiBNYWtlIDgtYnl0ZSBhbGlnbmVkLgoKLS0tIGdjYy90ZXN0 c3VpdGUvYy1jKystY29tbW9uL3RzYW4vcHI2NTQwMC0xLmMuamoJMjAxNS0w My0xOSAwODo1MzozOC4wMDAwMDAwMDAgKzAxMDAKKysrIGdjYy90ZXN0c3Vp dGUvYy1jKystY29tbW9uL3RzYW4vcHI2NTQwMC0xLmMJMjAxNi0wMi0xNSAx MTowOToxOC44NTIzMjA4MjcgKzAxMDAKQEAgLTcsOSArNyw5IEBACiAjaW5j bHVkZSAidHNhbl9iYXJyaWVyLmgiCiAKIHN0YXRpYyBwdGhyZWFkX2JhcnJp ZXJfdCBiYXJyaWVyOwotaW50IHY7Ci1pbnQgcTsKLWludCBvOworaW50IHYg X19hdHRyaWJ1dGVfXygoYWxpZ25lZCg4KSkpOworaW50IHEgX19hdHRyaWJ1 dGVfXygoYWxpZ25lZCg4KSkpOworaW50IG8gX19hdHRyaWJ1dGVfXygoYWxp Z25lZCg4KSkpOwogZXh0ZXJuIHZvaWQgYmF6NCAoaW50ICopOwogCiBfX2F0 dHJpYnV0ZV9fKChub2lubGluZSwgbm9jbG9uZSkpIGludAo= --_002_HE1PR07MB0905578859D3EC1C8AFFD5CFE4AC0HE1PR07MB0905eurp_--