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

> 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 openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org