From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1129 invoked by alias); 26 Apr 2017 10:07:37 -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 1052 invoked by uid 89); 26 Apr 2017 10:07:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=expecting, relationship, services X-Spam-User: qpsmtpd, 3 recipients X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 26 Apr 2017 10:07:35 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 860D2AB07; Wed, 26 Apr 2017 10:07:33 +0000 (UTC) Subject: Re: [PATCH] Fix test-case on ppc64le (PR testsuite/79455). To: Jakub Jelinek References: <0fca1de5-0203-f14a-d59e-e70664ce57ec@suse.cz> <20170424151939.GP1809@tucnak> <7df50141-5b92-d6f3-c993-86cdec053f58@suse.cz> Cc: GCC Patches , Segher Boessenkool , wschmidt@gcc.gnu.org, kelvin@gcc.gnu.org, bernd.edlinger@hotmail.de From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Wed, 26 Apr 2017 10:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7df50141-5b92-d6f3-c993-86cdec053f58@suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg01275.txt.bz2 On 04/26/2017 12:05 PM, Martin Liška wrote: > Received as HTML from Kelvin: > > I have reviewed some of the implementation details for pthread_mutex_init and pthread_mutex_lock, and have confirmed that ppc64 does use memset to initialize the entirety of its mutex lock structure before potentially overwriting a few of its fields with non-zero data. So in this regard, your fix seems appropriate. > > However, I'm confused about how this program runs. My understanding of the test case code is that the use of barrier_wait() calls is supposed to force Thread1 to run "to completion" before Thread2 even starts. So if my understanding is correct, it is not sensible for Thread1's pthread_mutex_init call to be followed "immediately" by Thread2's pthread_mutex_lock() call. > > The comment in tsan_barrier.h describes barrier_init and barrier_wait as "TSAN-invisible barriers". Can you help me understand how TSAN works in this regard? I was expecting that TSAN runs the program with instrumentation on the TSAN-visible "thread services" but no instrumentation on the TSAN-invisible thread services. Is this understanding correct? > > The questions I am trying to answer for myself are whether this test, as crafted, is really sufficiently "portable" and "meaningful". It seems to be making non-portable assumptions about the implementation of pthread_mutex_init and pthread_mutex_lock and pthread_mutex_unlock, even with the proposed change. > > Just to clarify: > Is it your understanding that the expected tsan diagnostic report is complaining that some data field of the mutex structure is being read in Thread 2 after having been written in Thread 1 without any "happens before" relationship (since tsan cannot see the barrier_wait calls?) Since the "conflict" is going all the way back to Thread 1's pthread_mutex_init call, am I correct in my understanding that the "first conflict noticed" is dealing with some part of the lock structure that is not normally modified by the execution of pthread_mutex_lock and pthread_mutex_unlock. > > Maybe adding a comment or two to the test case to clarify what is being tested would be most helpful here... > Well, I'm not the author neither of original test-case or modifications that added tsan_barrier.h. I'm CCing Bernd that can hopefully answer your questions. Martin