On Jan 21, 2015, at 6:41 AM, Dmitry Vyukov wrote:
> But I am somewhat tired of editing hundreds of files for today. Why
> did I write so many tests, stupid!?
:-) We appreciate all your efforts and all your tests.
On Jan 21, 2015, at 3:17 AM, Bernd Edlinger wrote:
> Hi Jakub & Mike,
>
>> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
>> internal-fn.c:243
>> void step (int i)
>
> It looks like your patches shot each other down..
Ah, I’d use the phrase one-step forward. Yeah, looks not
On Wed, Jan 21, 2015 at 5:38 PM, Bernd Edlinger
wrote:
> Hi,
>
> On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
>> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
>> To: bernd.edlin...@hotmail.de
>> CC: konstantin.s.serebry...@gmail.com; mikest...@comca
Hi,
On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
> To: bernd.edlin...@hotmail.de
> CC: konstantin.s.serebry...@gmail.com; mikest...@comcast.net;
> k...@google.com; ja...@redhat.com; richard.guent...@gmail.com;
&
Refactored tests in clang to use barrier_init/wait:
http://llvm.org/viewvc/llvm-project?view=revision&revision=226659
There are still few sleep call, like when we need to wait for a thread
to exit (there is really no point to insert barrier_wait); or when we
need to wait for a thread to _block_ in
On Wed, 21 Jan 2015 12:31:57, Jakub Jelinek wrote:
>
> On Wed, Jan 21, 2015 at 12:17:51PM +0100, Bernd Edlinger wrote:
>>> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
>>> internal-fn.c:243
>>> void step (int i)
>>
>>
>> It looks like your patches shot each other down..
>>
>>
On Wed, Jan 21, 2015 at 12:17:51PM +0100, Bernd Edlinger wrote:
> > test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
> > internal-fn.c:243
> > void step (int i)
>
>
> It looks like your patches shot each other down..
>
> How about this, maybe with a compile-time test of the st
Hi Jakub & Mike,
> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
> internal-fn.c:243
> void step (int i)
It looks like your patches shot each other down..
How about this, maybe with a compile-time test of the step function in
c-c++common/tsan?
Thanks
Bernd.
Hi,
On Wed, 21 Jan 2015 12:58:27, Dmitry Vyukov wrote:
>
>
> The step approach looks better to me at first sight.
>
> Busy waiting looks like a weak argument in this context. It's
> absolutely non performance-critical and a yield or usleep(10) will
> solve it more than sufficiently.
>
> I will ch
Well, OK, it is actually not easier to write tests with step function
as compared to barrier.
On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov wrote:
> On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>>
>>> [te
On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
wrote:
>
> Hi,
>
> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>
>> [text-only]
>>
>> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
I can't really make my mind on thi
Hi,
On Tue, 20 Jan 2015 17:47:29, Konstantin Serebryany wrote:
>>
>> We discussed two alternatives to sleep:
>>
>> 1. step function, optionally with sched_yield to make it somewhat less busy
>> waiting:
>> __attribute__((no_sanitize_thread))
>> void step (int i)
>> {
>> while (__atomic_load_n (&s
On Mon, Jan 19, 2015 at 11:09 PM, Bernd Edlinger
wrote:
>
> Hi,
>
> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>
>> [text-only]
>>
>> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
I can't really make my mind on thi
Hi,
On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>
> [text-only]
>
> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
>>> I can't really make my mind on this. I would mildly prefer sleep's (if
>>> they work reliably!).
>>
>>
[text-only]
On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
>> I can't really make my mind on this. I would mildly prefer sleep's (if
>> they work reliably!).
>
> Let me state it more forcefully.
You don't have to convince us here.
I'd love
On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
> I can't really make my mind on this. I would mildly prefer sleep's (if
> they work reliably!).
Let me state it more forcefully. sleeps are not now, nor in the history of
computing ever been a synchronization primitive, except for hard real ti
On Mon, Jan 19, 2015 at 12:43:39PM +0400, Dmitry Vyukov wrote:
> Hi Bernd,
>
> Yes, that email is marked in my inbox. Sorry for not answering earlier.
>
> I can't really make my mind on this. I would mildly prefer sleep's (if
> they work reliably!).
Sleeps by definition should not be reliable, n
On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>>
>> This is just a copy from llvm repo, right?
>> Looks good to me.
>>
>
> Thanks.
>
> Yes I found these test case in the llvm tree, and just adapted them
> to work in the gcc test
Hi,
On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>
> This is just a copy from llvm repo, right?
> Looks good to me.
>
Thanks.
Yes I found these test case in the llvm tree, and just adapted them
to work in the gcc test suite.
However, here is a small tweak in the positive test:
That is we
This is just a copy from llvm repo, right?
Looks good to me.
On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger
wrote:
> Hi,
>
>
> I think I should ping for this patch now:
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
>
> note that by mistake the change log referenced sanitizer.c inst
On 01/16/15 00:17, Bernd Edlinger wrote:
Hi,
I think I should ping for this patch now:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
note that by mistake the change log referenced sanitizer.c instead of
sanitizer.def, consider that fixed on my local copy.
That patch is fine. Thank
Hi,
I think I should ping for this patch now:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html
note that by mistake the change log referenced sanitizer.c instead of
sanitizer.def, consider that fixed on my local copy.
Thanks
Bernd.
> Date: Sun, 11 Jan 2015 14:15:54 +0100
>
> Hi,
>
>
22 matches
Mail list logo