Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.