From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26609 invoked by alias); 4 Jan 2015 17:00:27 -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 26591 invoked by uid 89); 4 Jan 2015 17:00:25 -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-OMC4S28.hotmail.com Received: from dub004-omc4s28.hotmail.com (HELO DUB004-OMC4S28.hotmail.com) (157.55.2.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Sun, 04 Jan 2015 17:00:24 +0000 Received: from DUB118-W8 ([157.55.2.71]) by DUB004-OMC4S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 4 Jan 2015 09:00:20 -0800 X-TMN: [zjoag4FEJWbIFKV09gpmBlO+jt7G400I] Message-ID: Content-Type: multipart/mixed; boundary="_e2062624-83f2-4df3-9f49-b0484a362339_" From: Bernd Edlinger To: Mike Stump , "H.J. Lu" 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, 04 Jan 2015 17:00:00 -0000 In-Reply-To: References: ,<3C12133C-DABF-40FA-94F7-9DB785F6E914@comcast.net>, MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg00088.txt.bz2 --_e2062624-83f2-4df3-9f49-b0484a362339_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1044 Aehm, sorry, that's the sporadic failure, I mentioned: https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00041.html New failures: FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test New passes: https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00044.html New failures: New passes: FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test Really I did run this test often, before I checked it in, but... It is due to a race condition in tsan itself, it cannot decide which access= was the previous one and which was the second one, but our tsan tests are not meant= as a functional test of the tsan runtime library, they are only meant to test = the GCC instrumentation. For the purpose of finding race conditions in an application a detection li= kelihood of 98% is absolutely perfect, just for our test suite that causes unnecessary fail= ures. So, I still think I should fix that test case, maybe with a comment, why I = have to sleep(1), what do you think? Bernd. =20=09=09=20=09=20=20=20=09=09=20=20= --_e2062624-83f2-4df3-9f49-b0484a362339_ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-tsan-race.diff" Content-length: 976 MjAxNS0wMS0wMyAgQmVybmQgRWRsaW5nZXIgIDxiZXJuZC5lZGxpbmdlckBo b3RtYWlsLmRlPgoKICAgICAgICAqIGcrKy5kZy90c2FuL2FsaWduZWRfdnNf dW5hbGlnbmVkX3JhY2UuQzogRml4ZWQgc3BvcmFkaWMgZmFpbHVyZS4KCgpJ bmRleDogZ2NjL3Rlc3RzdWl0ZS9nKysuZGcvdHNhbi9hbGlnbmVkX3ZzX3Vu YWxpZ25lZF9yYWNlLkMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gZ2Nj L3Rlc3RzdWl0ZS9nKysuZGcvdHNhbi9hbGlnbmVkX3ZzX3VuYWxpZ25lZF9y YWNlLkMJKHJldmlzaW9uIDIxOTE2MCkKKysrIGdjYy90ZXN0c3VpdGUvZysr LmRnL3RzYW4vYWxpZ25lZF92c191bmFsaWduZWRfcmFjZS5DCSh3b3JraW5n IGNvcHkpCkBAIC0yLDEwICsyLDE0IEBACiAjaW5jbHVkZSA8cHRocmVhZC5o PgogI2luY2x1ZGUgPHN0ZGlvLmg+CiAjaW5jbHVkZSA8c3RkaW50Lmg+Cisj aW5jbHVkZSA8dW5pc3RkLmg+CiAKIHVpbnQ2NF90IEdsb2JhbFsyXTsKIAog dm9pZCAqVGhyZWFkMSh2b2lkICp4KSB7CisgIC8qIFdlIGhhdmUgdG8gc2xl ZXAgaGVyZSwgdG8gbWFrZSBpdCBzb21ld2hhdCBlYXNpZXIgZm9yIHRzYW4g dG8KKyAgICAgZGV0ZWN0IHRoZSByYWNlIGNvbmRpdGlvbi4gICovCisgIHNs ZWVwKDEpOwogICBHbG9iYWxbMV0rKzsKICAgcmV0dXJuIE5VTEw7CiB9Cg== --_e2062624-83f2-4df3-9f49-b0484a362339_--