Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 15 Sep 2015 20:25:38 +0300
From: Solar Designer <>
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:

Thanks.  Some interesting stuff there.


""GCC does do strict-aliasing, but from my experience, not across
function boundaries." Even for inlined functions?   Nemo Jul 16 '14 at

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).


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.