Assembly optimisations cause build to fail when contradicting CXXFLAGS are used

luke-jr commented at 4:15 pm on July 25, 2018: member

When configuring with CXXFLAGS="-O1 -ggdb -Wall -mno-avx2"…

configure detects AVX by passing the -mavx -mavx2 flags after CXXFLAGS, so succeeds:

0configure:19622: checking whether C++ compiler accepts -mavx -mavx2
1configure:19641: g++ -std=c++11 -c -O1 -ggdb -Wall -mno-avx2 -Werror -mavx -mavx2  conftest.cpp >&5
2configure:19641: $? = 0

But then the build uses -mavx -mavx2 before CXXFLAGS, which fails:

 0/usr/bin/ccache g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../src/config   -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -DENABLE_AVX2 -DHAVE_BUILD_INFO -D__STDC_FORMAT_MACROS  -Wstack-protector -fstack-protector-all      -fPIE -mavx -mavx2 -O1 -ggdb -Wall -mno-avx2 -MT crypto/crypto_libbitcoin_crypto_avx2_a-sha256_avx2.o -MD -MP -MF crypto/.deps/crypto_libbitcoin_crypto_avx2_a-sha256_avx2.Tpo -c -o crypto/crypto_libbitcoin_crypto_avx2_a-sha256_avx2.o `test -f 'crypto/sha256_avx2.cpp' || echo './'`crypto/sha256_avx2.cpp
 1In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/immintrin.h:43:0,
 2                 from crypto/sha256_avx2.cpp:4:
 3/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/avx2intrin.h: In function ‘__m256i sha256d64_avx2::{anonymous}::Add(__m256i, __m256i)’:
 4/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/avx2intrin.h:119:1: error: inlining failed in call to always_inline ‘__m256i _mm256_add_epi32(__m256i, __m256i)’: target specific option mismatch
 5 _mm256_add_epi32 (__m256i __A, __m256i __B)
 6 ^~~~~~~~~~~~~~~~
 7crypto/sha256_avx2.cpp:14:72: note: called from here
 8 __m256i inline Add(__m256i x, __m256i y) { return _mm256_add_epi32(x, y); }
 9                                                                        ^
10make[2]: *** [Makefile:4533: crypto/crypto_libbitcoin_crypto_avx2_a-sha256_avx2.o] Error 1

IMO the better solution is to fix the build (ie, continue to build AVX support even with the contradicting CXXFLAGS) by passing -mavx -mavx2 after CXXFLAGS.

luke-jr commented at 4:16 pm on July 25, 2018: member

CC @laurentb

MarcoFalke added this to the milestone 0.17.0 on Jul 25, 2018

MarcoFalke added the label Build system on Jul 25, 2018

luke-jr commented at 4:20 pm on July 25, 2018: member

(on the other hand, simply fixing the build makes it impossible for users to avoid building specific assembly optimisations? maybe that’s better done with a hypothetical --disable-asm=sse4,avx or such)

laurentb commented at 5:51 pm on July 25, 2018: none

For the context, I use Gentoo, and my CFLAGS are basically an expanded -mnative (https://github.com/hartwork/resolve-march-native also does this).

0.16.0 was compiling fine but not 0.16.1.

luke-jr commented at 5:54 pm on July 25, 2018: member

(@laurentb means Knots 0.16.1, which has the assembly optimisations from master. The issue is confirmed to affect master also.)

luke-jr commented at 7:44 pm on July 28, 2018: member

Note that autotools (apparently intentionally) makes overriding user CXXFLAGS basically impossible, and also expects CXXFLAGS to be valid to change between configure and make, so there isn’t really a solution to this. For now, #13789 uses pragmas to force the required instructions enabled for the relevant files, but this only works with GCC and Clang.

MarcoFalke removed this from the milestone 0.17.0 on Aug 2, 2018

fanquake referenced this in commit 4349051dd4 on Aug 15, 2022

fanquake commented at 8:37 am on August 16, 2022: member

but this only works with GCC and Clang.

I’ve PR’d an alternative in #25852 that should work regardless of compiler.

MarcoFalke referenced this in commit 02aefa169a on Aug 19, 2022

MarcoFalke closed this on Aug 19, 2022

sidhujag referenced this in commit 2fcf9e0062 on Aug 19, 2022

Rspigler referenced this in commit e8231e98db on Aug 21, 2022

bitcoin locked this on Aug 19, 2023

Assembly optimisations cause build to fail when contradicting CXXFLAGS are used #13758