On 5/30/2013 06:45, dw wrote:
> On 5/24/2013 8:43 PM, dw wrote:
>> I looked at the hand-crafted and the built-in, and they both generate
>> the same code. In the end, I went with the __sync_fetch_and_OP()
>> built-in (attached). The comments above still apply.
>
> I'm going to wait for this patch
On 5/24/2013 8:43 PM, dw wrote:
I looked at the hand-crafted and the built-in, and they both generate
the same code. In the end, I went with the __sync_fetch_and_OP()
built-in (attached). The comments above still apply.
I'm going to wait for this patch to get committed before sending the
nex
On 05/20/2013 03:57 AM, dw wrote:
In summary, this patch:
1) Correctly returns the "old" value.
2) Uses builtin function instead of inline asm.
3) Fixes both winnt.h and the crt intrinsic files.
4) Uses intrin-mac.h to avoid duplicating code.
On 5/24/2013 2:43 PM, Václav Zeman wrote:
I thin
On 05/20/2013 03:57 AM, dw wrote:
> There is a bug in the InterlockedOr function (as well as InterlockedAnd,
> InterlockedXor, InterlockedOr64, InterlockedAnd64, InterlockedXor64)
> where they do not return the "old" value as expected, but instead return
> (sort of) the new value. This code illust
2013/5/23 dw :
> In summary, this patch:
>
> 1) Correctly returns the "old" value.
> 2) Uses builtin function instead of inline asm.
>
> Nice catch. Patch is ok. Could you please also prepare patch for
> crt's intrinsic-implementation files?
>
>
> As before, plus:
>
> 3) Fixes both winnt.h and the
In summary, this patch:
1) Correctly returns the "old" value.
2) Uses builtin function instead of inline asm.
Nice catch. Patch is ok. Could you please also prepare patch for
crt's intrinsic-implementation files?
As before, plus:
3) Fixes both winnt.h and the crt intrinsic files.
4) Uses int
2013/5/21 dw :
>
>> the idea to put all intrinsics within one new header, I don't like
>> either.
> Sorry, my fault. I wasn't clear. This isn't what I was proposing.
>
> I'm suggesting intrnmac.h only contains the macro definitions. So we
> would move this code from winnt.h (which is where it is
> the idea to put all intrinsics within one new header, I don't like
> either.
Sorry, my fault. I wasn't clear. This isn't what I was proposing.
I'm suggesting intrnmac.h only contains the macro definitions. So we
would move this code from winnt.h (which is where it is now) to intrnmac.h:
2013/5/21 dw :
>
>> Could you please also prepare patch for crt's intrinsic-implementation
>> files?
> I've been pondering how to do this, both for the InterlockedOr functions
> and the __stos* functions. Duplicating the same code in two places goes
> against my nature. I figure the best answer w
> Could you please also prepare patch for crt's intrinsic-implementation
> files?
I've been pondering how to do this, both for the InterlockedOr functions
and the __stos* functions. Duplicating the same code in two places goes
against my nature. I figure the best answer would be to define the
2013/5/20 dw :
> There is a bug in the InterlockedOr function (as well as InterlockedAnd,
> InterlockedXor, InterlockedOr64, InterlockedAnd64, InterlockedXor64) where
> they do not return the "old" value as expected, but instead return (sort of)
> the new value. This code illustrates the problem:
There is a bug in the InterlockedOr function (as well as InterlockedAnd,
InterlockedXor, InterlockedOr64, InterlockedAnd64, InterlockedXor64)
where they do not return the "old" value as expected, but instead return
(sort of) the new value. This code illustrates the problem:
#include
#include
12 matches
Mail list logo
