Date: Tue, 15 Sep 2015 20:25:38 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Strict aliasing in SIMD code Hi Lei, On Tue, Sep 15, 2015 at 11:33:04PM +0800, Lei Zhang wrote: > I was thinking about polishing the pseudo-intrinsics for NEON and AltiVec when this topic came to me. We've discussed it before, but I don't think we've really fixed this issue in JtR so far. I found an interesting SO link that's related to our problem and might be worth reading: http://stackoverflow.com/questions/24787268/how-to-implement-mm-storeu-epi64-without-aliasing-problems Thanks. Some interesting stuff there. Regarding: ""GCC does do strict-aliasing, but from my experience, not across function boundaries." Even for inlined functions? Nemo Jul 16 '14 at 18:38" I can say that GCC does strict-aliasing across boundaries of inlined functions. This is what broke crypto_scrypt-nosse.c in some builds. > Maybe we need not worry about strict-aliasing anymore when using SIMD intrinsics, as (most) compilers are already taking care of this issue for us. For x86, it appears so (and it may be why crypto_scrypt-sse.c didn't break, while -nosse did). For other archs, it's less obvious. gcc does sometimes emit strict aliasing violation warnings for my intrinsics code in DES_bs_b.c. I am not entirely sure, but I think I only saw those warnings in non-x86 builds (meaning NEON and AltiVec). 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.