[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150707143521.GA8967@openwall.com>
Date: Tue, 7 Jul 2015 17:35:21 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: AltiVec troubleshooting
On Tue, Jul 07, 2015 at 09:48:13PM +0800, Lei Zhang wrote:
> I think I met with some nasty compiler issue again, on Power this time.
>
> In pseudo-intrinsics, there's a intrinsic 'vcmov', which is available in XOP(_mm_cmov_si128), and emulated on other archs in a same way:
>
> #define vcmov(y, z, x) vxor(z, vand(x, vxor(y, z)))
This operation is available natively on AltiVec and NEON, so you
shouldn't be emulating it there. From DES_bs_b.c:
#elif defined(__ALTIVEC__) && DES_BS_DEPTH == 128
[...]
#define vsel(dst, a, b, c) \
(dst) = vec_sel((a), (b), (vector bool int)(c))
> But somehow, this emulation won't give correct result on Power. I looked the preprocessed code generated by 'gcc -E', and found the compiler generated some weird code for 'vcmov'. I give a simplified example here:
You're clearly running into some C preprocessor issue here, but the
cause might be some error in your source code or testing (C preprocessor
bug like this is very unlikely). I am not spending time to look into it.
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.
