LGTM with my limited gcc internals knowledge
On Sat, Dec 1, 2012 at 3:56 AM, Jakub Jelinek wrote:
> On Fri, Nov 30, 2012 at 09:00:30PM +0400, Dmitry Vyukov wrote:
>> and thanks for the nand catch!
>
> Here is updated atomics instrumentation patch, including the 16-byte
> atomics, nand, success/fa
On Fri, Nov 30, 2012 at 09:00:30PM +0400, Dmitry Vyukov wrote:
> and thanks for the nand catch!
Here is updated atomics instrumentation patch, including the 16-byte
atomics, nand, success/failure parameters for cas and 0-5 arguments
instead of 1<<0 through 1<<5 for memory models.
Again, on top of
and thanks for the nand catch!
On Fri, Nov 30, 2012 at 9:00 PM, Dmitry Vyukov wrote:
> On Fri, Nov 30, 2012 at 8:38 PM, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
>>> Yes, you are right.
>>> I think I've done them atomically initially because of things
On Fri, Nov 30, 2012 at 8:38 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
>> Yes, you are right.
>> I think I've done them atomically initially because of things like
>> FUTEX_WAKE_OP. I will fix that.
>
> Any progress on that?
>
> BTW, the current
> te
On Tue, Nov 27, 2012 at 12:47:50PM +0400, Dmitry Vyukov wrote:
> Yes, you are right.
> I think I've done them atomically initially because of things like
> FUTEX_WAKE_OP. I will fix that.
Any progress on that?
BTW, the current
template T func_nand(T v, T op) {
return ~v & op;
}
is wrong not jus
On Tue, Nov 27, 2012 at 4:39 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 04:35:33PM +0400, Dmitry Vyukov wrote:
>> On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
>> > On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
>> >> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitr
On Tue, Nov 27, 2012 at 04:35:33PM +0400, Dmitry Vyukov wrote:
> On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
> > On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
> >> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> >> > I've added 128-bit atomic ops:
> >> >
On Tue, Nov 27, 2012 at 4:27 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>> > I've added 128-bit atomic ops:
>> > http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>>
>> Thank
On Tue, Nov 27, 2012 at 09:23:30AM +0100, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> > I've added 128-bit atomic ops:
> > http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>
> Thanks.
+#if (defined(__clang__) && defined(__clang_major__) \
+
On Tue, Nov 27, 2012 at 12:47 PM, Dmitry Vyukov wrote:
> On Tue, Nov 27, 2012 at 12:23 PM, Jakub Jelinek wrote:
>> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>>> I've added 128-bit atomic ops:
>>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>>
>> Thanks.
>>>
>
On Tue, Nov 27, 2012 at 12:23 PM, Jakub Jelinek wrote:
> On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
>> I've added 128-bit atomic ops:
>> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
>
> Thanks.
>>
>> Refactored atomic ops so that the atomic operation itself is d
On Tue, Nov 27, 2012 at 12:13:42PM +0400, Dmitry Vyukov wrote:
> I've added 128-bit atomic ops:
> http://llvm.org/viewvc/llvm-project?view=rev&revision=168683
Thanks.
>
> Refactored atomic ops so that the atomic operation itself is done
> under the mutex:
> http://llvm.org/viewvc/llvm-project?vie
On Fri, Nov 23, 2012 at 6:05 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to instrument __atomic_* and __sync_* builtins.
> Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> replacements, tsan uses weirdo memory model encoding (instead of values
> from 0 to 5 appa
On Fri, Nov 23, 2012 at 6:05 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to instrument __atomic_* and __sync_* builtins.
> Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> replacements, tsan uses weirdo memory model encoding (instead of values
> from 0 to 5 appa
On Mon, Nov 26, 2012 at 9:07 PM, Xinliang David Li wrote:
>>> >>> Ok. A slight problem then is that where the tsan pass sits right now,
>>> >>> there
>>> >>> is no easy way to find out if the builtin call will be expanded inline
>>> >>> or
>>> >>> not, so (similar for asan), if we instrument th
On Mon, Nov 26, 2012 at 12:35 AM, Jakub Jelinek wrote:
> On Mon, Nov 26, 2012 at 12:17:44PM +0400, Dmitry Vyukov wrote:
>> On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov wrote:
>> >>> Ok. A slight problem then is that where the tsan pass sits right now,
>> >>> there
>> >>> is no easy way to fi
On Sat, Nov 24, 2012 at 3:06 PM, Dmitry Vyukov wrote:
>
> On Fri, Nov 23, 2012 at 8:39 PM, Jakub Jelinek wrote:
> > On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
> >> > This patch attempts to instrument __atomic_* and __sync_* builtins.
> >> > Unfortunately for none of the builti
On Mon, Nov 26, 2012 at 12:17:44PM +0400, Dmitry Vyukov wrote:
> On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov wrote:
> >>> Ok. A slight problem then is that where the tsan pass sits right now,
> >>> there
> >>> is no easy way to find out if the builtin call will be expanded inline or
> >>> no
On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov wrote:
>>> Ok. A slight problem then is that where the tsan pass sits right now, there
>>> is no easy way to find out if the builtin call will be expanded inline or
>>> not, so (similar for asan), if we instrument them in the pass, it might be
>>> i
On Fri, Nov 23, 2012 at 8:39 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
>> > This patch attempts to instrument __atomic_* and __sync_* builtins.
>> > Unfortunately for none of the builtins there is 1:1 mapping to the tsan
>> > replacements, tsan uses
On Fri, Nov 23, 2012 at 9:07 PM, Xinliang David Li wrote:
> On Fri, Nov 23, 2012 at 8:39 AM, Jakub Jelinek wrote:
>> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
>>> > This patch attempts to instrument __atomic_* and __sync_* builtins.
>>> > Unfortunately for none of the builtin
On Sat, Nov 24, 2012 at 12:11 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
>> I've just committed a patch to llvm with failure_memory_order (r168518).
>
> Shouldn't it be something like this instead?
>
> --- tsan_interface_atomic.cc.jj 2012-11-23 17:20:
On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
> I've just committed a patch to llvm with failure_memory_order (r168518).
Shouldn't it be something like this instead?
--- tsan_interface_atomic.cc.jj 2012-11-23 17:20:49.0 +0100
+++ tsan_interface_atomic.cc2012-11-23 19:
On Fri, Nov 23, 2012 at 8:39 AM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
>> > This patch attempts to instrument __atomic_* and __sync_* builtins.
>> > Unfortunately for none of the builtins there is 1:1 mapping to the tsan
>> > replacements, tsan uses
On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
> > This patch attempts to instrument __atomic_* and __sync_* builtins.
> > Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> > replacements, tsan uses weirdo memory model encoding (instead of values
> > from 0 t
Hi!
This patch attempts to instrument __atomic_* and __sync_* builtins.
Unfortunately for none of the builtins there is 1:1 mapping to the tsan
replacements, tsan uses weirdo memory model encoding (instead of values
from 0 to 5 apparently 1 << 0 to 1 << 5, as if one could have more than
one memory
26 matches
Mail list logo
