Message ID | 20200727111402.14786-2-harry.van.haaren@intel.com |
---|---|
State | Superseded |
Headers | show |
Series | [ovs-dev,1/2] configure: fix binutils check not disabling avx512 compilation | expand |
diff --git a/m4/openvswitch.m4 b/m4/openvswitch.m4 index 7c9a507e5..6fe79297e 100644 --- a/m4/openvswitch.m4 +++ b/m4/openvswitch.m4 @@ -426,8 +426,12 @@ AC_DEFUN([OVS_CHECK_BINUTILS_AVX512], CFLAGS="$CFLAGS -DHAVE_LD_AVX512_GOOD" else ovs_cv_binutils_avx512_good=no + dnl Explicitly disallow avx512f to stop compiler auto-vectorizing + dnl and causing zmm usage with buggy binutils versions. + CFLAGS="$CFLAGS -mno-avx512f" fi else + dnl non x86_64 architectures don't have avx512, so not affected ovs_cv_binutils_avx512_good=no fi]) rm $OBJFILE
This commit explicitly disables avx512f if the binutils assembler check fails to correctly assemble its input. Without this fix, there is a possibility that users can see undefined behaviour when compiling with -march=native on a CPU which supports avx512 and with a buggy binutils version (v2.30 and 2.31), without a backported fix, if the compiler's vectorizing optimizations convert scalar code to avx512 instructions. Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com> --- Note that the compiler autovectorization with binutils bug could be present in previous releases, and was not introduced with the 2.14 dpcls avx512 optimizations. The adding of avx512 to dpcls required the binutils checks, resulting in a shorter fix to this issue. --- m4/openvswitch.m4 | 4 ++++ 1 file changed, 4 insertions(+)