[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 May 2012 04:29:45 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Myrice: Weekly Report #5
myrice -
On Wed, May 16, 2012 at 04:21:22PM +0800, myrice wrote:
> Now I think it is only the SWAP64. Maybe I have to change it into
> other forms. But from my experiment, if followings are true, I think
> the problem is complex and all 64bit operation will be influenced.
>
> I find problems with bit operation like: &, | and <<.
> I think compiler optimization does something strange. If I use two of
> bit operations in a sentence like: n = (a & 0xff) << 32, the result
> will be 0 when the operation on high 32bit of a 64bit variable.
> I have tried using violate variables to avoid this. Such as: violate
> ulong a; a &= 0xff; n = a << 32; This would be correct. If I use a for
> next sentence, the a will be 0 also.
>
> I suspect the AMD OpenCL compiler has some bugs with 64bit bit operation.
By "violate", do you mean "volatile"?
Like Frank suggested, can you generate a simple testcase? Not only for
posting to AMD forums, but also to let others on our team test it on
other GPUs. From Samuele's test of your entire XSHA512 kernel, it is
unclear whether the self-test failed for the same reason or maybe for
another reason. A smaller testcase with some debugging output would
make this clearer.
Thanks,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
