For reference, note that Linux version avoids __intel_fast_memcpy with
-Dmemcpy=__builtin_memcpy, because libirc.a caused griefs when linked
into shared library. __intel_fast_memcpy feels as overkill in OpenSSL
context and inlined code [movs or unrolled loop] should do better job.
Can you try to compile with -Dmemcpy=__builtin_memcpy
-Dmemset=__builting_memset?
I get
unresolved external symbol __builtin_memcpy
unresolved external symbol __builtin_memset
Ouch! Something to look into when 9 is available for Linux...
It seems like memcpy should be replaced with memmove here?
Does it mean that you've tried to replace it with memmove and can
confirm that DES works if compiled with ICC /O2 or higher? It actually
smells more like compiler bug than memcpy vs. memmove issue...
Yes, DES works with memmove and breaks with memcpy for /O2 and higher.
Fix commited.
3) Is AES really a lot faster on Win64/x64 compared to the i586 asm
version or am I doing something wrong?
1. Who says that AES is assembler empowered on Win32? It's not, not yet:-)
I assumed that the asm file was used since it was included...
There're couple of other assembler code-pathes which are not engaged on
VC-WIN32. Most notably SSE2 codes in BN and SHA512 and P4 specific RC4. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
