When attempting to compile the ebuild crypto++-8.2.0 it fails if your CFLAGS/CXXFLAGS has the bdver1 architecture. If you add "-mno-fma4" the ebuild then compiles successfully with no errors. "-march=bdver2" also works with no errors. This has been verified by one other person on #gentoo by the nickname of iamben.
Created attachment 581760 [details] Build log Build log for crypto++8.2.0 when using march of bdver1 without disabling fma4
CXXFLAGS="-march=bdver1" -> FAIL CXXFLAGS="-march=bdver1 -mbmi" -> SUCCESS CXXFLAGS="-march=bdver1 -mno-fma4" -> SUCCESS
Please disable asm USE for now
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d116b2a7d690b9a9717b7b97b8c67eda503756e3 commit d116b2a7d690b9a9717b7b97b8c67eda503756e3 Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2019-07-02 16:48:35 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2019-07-02 16:49:59 +0000 dev-libs/crypto++: add explicit cpu_flags_x86 flag Closes: https://bugs.gentoo.org/show_bug.cgi?id=689162 Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 dev-libs/crypto++/crypto++-8.2.0-r1.ebuild | 60 ++++++++++++++++++++++ dev-libs/crypto++/files/crypto++-8.2.0-build.patch | 11 ++++ dev-libs/crypto++/metadata.xml | 1 + 3 files changed, 72 insertions(+)
Please try dev-libs/crypto++-8.2.0-r1 if not working, please attach emerge --info output
We are trying to figure out the header we need with GCC. Neither <immintrin.h> or <ammintrin.h> are bringing in the symbol even though __XOP__ is defined in the preprocessor. Also see Which header for AMD XOP _mm_roti_epi64?, https://gcc.gnu.org/ml/gcc-help/2019-07/msg00032.html . (XOP rotates are fast, and I don't like to see it disabled).
Here's a reproducer. We will likely have to file a GCC bug report for the issue. bulldozer:~$ g++ -march=bdver1 -msse4.1 test.cxx test.cxx: In function ‘int main(int, char**)’: test.cxx:14:9: error: ‘_mm_roti_epi64’ was not declared in this scope b = _mm_roti_epi64(a, 1); ^~~~~~~~~~~~~~ test.cxx:14:9: note: suggested alternative: ‘_mm_srli_epi64’ b = _mm_roti_epi64(a, 1); ^~~~~~~~~~~~~~ _mm_srli_epi64 bulldozer:~$ cat test.cxx #ifdef __XOP__ #include <immintrin.h> #include <ammintrin.h> #endif #ifdef __SSE41__ #include <smmintrin.h> #endif int main(int argc, char* argv[]) { __m128i a=_mm_setzero_si128(), b=_mm_setzero_si128(), c; #ifdef __XOP__ b = _mm_roti_epi64(a, 1); #endif #ifdef __SSE41__ c = _mm_blend_epi16(a, b, 0); #endif return 0; }
Crypto++ is tracking the issue at https://github.com/weidai11/cryptopp/issues/859 .
(In reply to Jeffrey Walton from comment #8) > Crypto++ is tracking the issue at > https://github.com/weidai11/cryptopp/issues/859 . Thanks!
This should clear the issue: https://github.com/weidai11/cryptopp/commit/eeb7dadc7657 We had to use that awful <x86intrin.h> header. GCC did not use a standard header like <ammintrin.h>. The <x86intrin.h> header has been a bane for us. It is not available on may platforms, and it often leads to compile failures. We gutted it after a string of compile failures due to rdrand and rdseed. The short of the eeb7dadc7657 change is, *_simd.cpp files that use XOP now do this gyration: #if defined(__XOP__) # include <ammintrin.h> # if defined(__GNUC__) # include <x86intrin.h> # endif #endif I'm not sure why we did not detect the problem earlier. I have a Bulldozer machine, and our test script is run on it. The test script uses -march=native (but not -march=bdver1). In fact, I ran it two days earlier and the XOP gear tested OK.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac1362559f5f84d43e121b0899927e8b9a15b741 commit ac1362559f5f84d43e121b0899927e8b9a15b741 Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2019-07-03 18:58:19 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2019-07-03 18:58:58 +0000 dev-libs/crypto++: fix amd64 asm Closes: https://bugs.gentoo.org/show_bug.cgi?id=689162 Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 ...++-8.2.0-r1.ebuild => crypto++-8.2.0-r2.ebuild} | 0 dev-libs/crypto++/crypto++-8.2.0.ebuild | 4 + dev-libs/crypto++/files/crypto++-8.2.0-build.patch | 260 +++++++++++++++++++++ 3 files changed, 264 insertions(+)
