This may cause GH #300, "Clang 3.9 and missing member definitions for template classes" or GH #294, "Fix clang warnings about undefined variable templates in pkcspad.h" to resurface. Man I hope not...
This may cause GH #300, "Clang 3.9 and missing member definitions for template classes" or GH #294, "Fix clang warnings about undefined variable templates in pkcspad.h" to resurface. Man I hope not...
We were cating UBsan findings under Clang similar to "adv-simd.h:1138:26: runtime error: addition of unsigned offset to 0x000002d41410 overflowed to 0x000002d41400". The problem was CRYPTOPP_CONSTANT, which used an enum. The compiler is allowed to pick the underlying data type, and Clang was picking a signed type
* GNUmakefile-cross: Fix install target
The install target was not working: missing mkdir before copying files,
wrong dynamic library copied, missing ldconf.
The fix is mostly taken from the install target from GNUmakefile.
* Makefile: call 'ln -sf' instead of 'ln -sf -sf'
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
Power4 lacks 'vector long long'
Rename datatypes such as 'uint8x16_p8' to 'uint8x16_p'. Originally the p8 suffix indicated use with Power8 in-core crypto. We are now using Altivec/Power4 for general vector operations.
AES does not have a NEON implementation. However, because it includes "adv-simd.h", it needs the compiler options so NEON types are available. Otherwise the compile fails.
We can't guard "adv-simd.h" and NEON on just AES because Simon and Speck use the templates in their NEON implementations.
This also fixes the SPECK64 bug where CTR mode self tests fail. It was an odd failure because it only affected 64-bit SPECK. SIMON was fine and it used nearly the same code. We tracked it down through trial and error to the table based rotates.
It looks like the delay was due to some GCC 7 issue. We had to disable parallel blocks on Aarch64 with GCC 7. We may be running out of registers and that could be causing problems. It looks like GCC uses up to v30.
For Simon-64 and Speck-64 this means we are effectively using 12x-4x-1x. We are mostly at the threshold for IA-32 and parallelization. At any time 10 to 13 XMM registers are being used.
Prefer movsd by way of _mm_load_sd and _mm_store_sd.
Fix "error C3861: _mm_cvtsi128_si64x identifier not found".
Jeffrey Walton
zorun