As done with others tests. This will avoid a miss-detection of aarch64 features
when using flags such as _FORTIFY_SOURCE that needs to be filtered for testing
This fixes https://github.com/weidai11/cryptopp/issues/812
V2: Fix all cases
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
The makefile tries to pre-qualify NEON (for lack of a better term), and sets IS_NEON accordingly. If IS_NEON=1, then we go on to perform test compiles to see if -mfloat-abi=X -mfpu=neon (and friends) actually work. Effectively we are performing a test to see if we should perform another test.
The IS_NEON flag predates our compile time feature tests. It was kind of helpful when we were trying to sort out if a platform and compiler options supported NEON without a compile test. That was an absolute mess and we quickly learned we needed a real compile time feature test (which we now have).
Additionally, Debian and Fedora ARMEL builds are failing because we are misdetecting NEON availability. It looks like we fail to set IS_NEON properly, so we never get into the code paths that set either (1) -mfloat-abi=X -mfpu=neon or (2) -DCRYPTOPP_DISABLE_NEON or -DCRYPTOPP_DISABLE_ASM. Later, the makefile builds a *_simd.cpp and the result is an error that NEON needs to be activated (or disabled).
This commit removes IS_NEON so we immediately move to compile time feature tests.
I thought this was due to trying to call the darn instruction even though g_hasDARN == false on Power8. However, the problem turned out to be a Power9 load was used when DARN class threw a DARN_Err.
This will allow users to specify agreesive warning flags without accidentally failing a feature test. The feature tests are minimal but the system headers could be noisy under elevated warnings
The CORE function provides the implementation for ChaCha_OperateKeystream_ALTIVEC, ChaCha_OperateKeystream_POWER7, BLAKE2_Compress32_ALTIVEC and BLAKE2_Compress32_POWER7. Depending on the options used to compile the source files, either POWER7 or ALTIVEC will be used.
This is needed to support the "new toolchain, ancient hardware" use case.
GCM can do some bulk XOR's using the SIMD unit. However, we still need loads and stores to be fast. Fast loads and stores of unaligned data requires the VSX unit
Nicolas Chauvet (kwizart)
Jeffrey Walton
Tanzinul Islam