This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Tom de Vries <Tom_deVries at mentor dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Dodji Seketeli <dodji at redhat dot com>, Kostya Serebryany <kcc at google dot com>, "thread-sanitizer at googlegroups dot com" <thread-sanitizer at googlegroups dot com>
- Date: Mon, 15 Feb 2016 13:45:58 +0100
- Subject: Re: [RFC, PR68580] Handle pthread_create error in tsan testsuite
- Authentication-results: sourceware.org; auth=none
- References: <HE1PR07MB090529F0173D75A4621D5FD6E4AC0 at HE1PR07MB0905 dot eurprd07 dot prod dot outlook dot com> <56C1AC43 dot 4070309 at mentor dot com> <CACT4Y+b0nXH3NWhWHiaMt_M82kUuMckOnehY1DsOJ9d=4qi0Ug at mail dot gmail dot com> <HE1PR07MB0905578859D3EC1C8AFFD5CFE4AC0 at HE1PR07MB0905 dot eurprd07 dot prod dot outlook dot com> <CACT4Y+ZLfqHKGcVroX41sj5E86ZCseAtj0WQOScTiNnsmnsUrw at mail dot gmail dot com> <HE1PR07MB0905A00928876B311A065C48E4AC0 at HE1PR07MB0905 dot eurprd07 dot prod dot outlook dot com>
On Mon, Feb 15, 2016 at 1:44 PM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
> On 15/02/16 13:05, Dmitry Vyukov wrote:
>> On Mon, Feb 15, 2016 at 12:29 PM, Bernd Edlinger
>> <bernd.edlinger@hotmail.de> wrote:
>>>
>>> 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?
>>
>>
>> I don't know whether it will fire or not, but 4-byte variables that
>> are 8-byte aligned can still be collocated with something else. Making
>> vars 8-byte should be safer.
>
> Yes, but as PR65400 is a wrong code bug, I would not like to change more
> than absolutely necessary to the test case, in order not to loose the ability
> to check the original regression.
>
> The test case does not have more than the 3 global values that you see.
> nm a.out | sort shows that these are now separate:
>
> 0000000000601400 b barrier
> 0000000000601420 b barrier_wait
> 0000000000601428 B v
> 0000000000601430 B o
> 0000000000601438 B q
> 0000000000601440 B _end
Looks good to me then.