Both BLAKE2 and SPECK slow down when using NEON/ASIMD. When just BLAKE2 experienced the issue, it was a one-off problem. Its now wider than a one-off, so add the formal define
* Set default target Windows version for MinGW to XP
The original MinGW from mingw.org targets Windows 2000 by default, but lacks
the <wspiapi.h> include needed for Windows 2000 support.
* Disable CRYPTOPP_CXX11_SYNCHRONIZATION for original MinGW
std::mutex is only available in libstdc++ if _GLIBCXX_HAS_GTHREADS is defined,
which is not the case for original MinGW. Make the existing fix for AIX more
general to fix this. Unfortunately, any C++ header has to be included to
detect the standard library and the otherwise empty <ciso646> is going to be
removed from C++20, so use <cstddef> instead.
This cleans up the compile on old PwerMac G5's. Our Altivec and Crypto code relies on Power7 and Power8 extensions. There's no need to shoehorn Altivec and Power4 into old platforms, so we disable Altivec and Crypto unless Power7 is available. The GNUmakefile sets CRYPTOPP_DISABLE_ALTIVEC if Power7 is not available.
Enable aligned allocations under IBM XL C/C++. Based on the AIX malloc man pages, "... the block is aligned so that it can be used for any type of data". Previously CRYPTOPP_NO_ALIGNED_ALLOC was in effect.
Use malloc instead of calloc on OS X. Based on the OS X malloc man pages, "... the allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types". Additionally, calloc zero'd the memory it allocated which slowed things down on Apple systems.
We determine machine capabilities by performing an os/platform *query* first, like getauxv(). If the *query* fails, we move onto a cpu *probe*. The cpu *probe* tries to exeute an instruction and then catches a SIGILL on Linux or the exception EXCEPTION_ILLEGAL_INSTRUCTION on Windows. Some OSes fail to hangle a SIGILL gracefully, like Apple OSes. Apple machines corrupt memory and variables around the probe.
The strategy of "cleanup under-aligned buffers" is not scaling well. Corner cases are still turing up. The library has some corner-case breaks, like old 32-bit Intels. And it still has not solved the AltiVec and Power8 alignment problems.
For now we are backing out the changes and investigating other strategies
Currently the CRYPTOPP_BOOL_XXX macros set the macro value to 0 or 1. If we remove setting the 0 value (the #else part of the expression), then the self tests speed up by about 0.3 seconds. I can't explain it, but I have observed it repeatedly.
This check-in prepares for the removal in Upstream master
I wish GCC would get its head out of its ass and define the apprpriate defines. NEON/ASIMD cannot be disgorged from Aarch32/Aarch64 just like SSE2 cannot be disgorged from x86_64. They are core instruction sets
CRYPTOPP_NO_UNALIGNED_DATA_ACCESS was required in Crypto++ 5.6 and earlier because unaligned data access was the norm. It caused problems at -O3 and on ARM NEON.
At Crypto++ 6.0 no unaligned data access became a first class citizen. Folks who want to allow it must now define CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS
When compiling with Visual Studio 2015+, Crypto++ uses CryptoNG by
default. CryptoNG is only available on Windows Vista and later and
Crypto++ currently ignores if the user explicitly wants to target
Windows XP. Unlike with other Windows SDK features, everything
compiles, but the application doesn't start on Windows XP because
bcrypt.dll is missing. That is an issue when updating Visual Studio
because the root cause is hard to find.
Making use of CryptoNG when targeting Windows 8+ instead by default,
regardless of the Visual Studio version, to fix this.
This reverts commit eb3b27a6a5. The change broke GCC 4.8 and unknown version of Clang on OS X. UB reported the OS X break, and JW found duplicated the break on a ARM CubieTruck with GCC 4.8.
Most of these appear to have been cleared over the last couple of years.
C4127 is too prevelant. We are probably going to have to live with it.
We may be able to clear C4250 with a using statement. For example 'using ASN1CryptoMaterial::Load'.
MSVC resisted clearing C4661 by pushing/poping in iterhash.h and osrng.h. It was like MSVC simply ignored it.
Jeffrey Walton
Marcel Raad