OpenBLAS: Building with native Apple Clang fails if NO_AVX512 not set
It seems that a build with GFortran 9 and Apple clang version 11.0.0 (clang-1100.0.33.17) fails unless NO_AVX512 is set in the environment.
This was discovered while updating the Homebrew formula. I suspect something similar may happen when using GCC 9 for C and Fortran too.
Here is what the build & environment look like:
DYNAMIC_ARCH=1
USE_OPENMP=1
make CC=clang FC=gfortran libs netlib shared
make PREFIX=/usr/local/Cellar/openblas/0.3.8 install
And here are the errors we see during CI:
15:22:04 ==> make CC=clang FC=gfortran libs netlib shared
15:22:04 make[1]: warning: -jN forced in submake: disabling jobserver mode.
15:22:04 clang -O2 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=6 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"0.3.8\" -DASMNAME=_saxpy -DASMFNAME=_saxpy_ -DNAME=saxpy_ -DCNAME=saxpy -DCHAR_NAME=\"saxpy_\" -DCHAR_CNAME=\"saxpy\" -DNO_AFFINITY -I.. -I. -UDOUBLE -UCOMPLEX -c axpy.c -o saxpy.o
15:22:04 clang -O2 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=6 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"0.3.8\" -DASMNAME=_sswap -DASMFNAME=_sswap_ -DNAME=sswap_ -DCNAME=sswap -DCHAR_NAME=\"sswap_\" -DCHAR_CNAME=\"sswap\" -DNO_AFFINITY -I.. -I. -UDOUBLE -UCOMPLEX -c swap.c -o sswap.o
...
[snip]
...
15:53:55 clang -c -O2 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -fopenmp -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=6 -DMAX_PARALLEL_NUMBER=1 -DVERSION=\"0.3.8\" -DASMNAME=_sgemv_t_SKYLAKEX -DASMFNAME=_sgemv_t_SKYLAKEX_ -DNAME=sgemv_t_SKYLAKEX_ -DCNAME=sgemv_t_SKYLAKEX -DCHAR_NAME=\"sgemv_t_SKYLAKEX_\" -DCHAR_CNAME=\"sgemv_t_SKYLAKEX\" -DNO_AFFINITY -DTS=_SKYLAKEX -I.. -DBUILD_KERNEL -DTABLE_NAME=gotoblas_SKYLAKEX -march=skylake-avx512 -UDOUBLE -UCOMPLEX -UDOUBLE -UCOMPLEX -DTRANS ../kernel/x86_64/sgemv_t_4.c -o sgemv_t_SKYLAKEX.o
15:53:55 In file included from ../kernel/x86_64/saxpy.c:37:
15:53:55 ../kernel/x86_64/saxpy_microk_skylakex-2.c:41:13: error: always_inline function '_mm256_broadcastss_ps' requires target feature 'avx2', but would be inlined into function 'saxpy_kernel_16' that is compiled without support for 'avx2'
15:53:55 __alpha = _mm256_broadcastss_ps(_mm_load_ss(alpha));
15:53:55 ^
15:53:55 ../kernel/x86_64/saxpy_microk_skylakex-2.c:60:3: error: always_inline function '_mm256_storeu_ps' requires target feature 'avx', but would be inlined into function 'saxpy_kernel_16' that is compiled without support for 'avx'
15:53:55 _mm256_storeu_ps(&y[i + 0], _mm256_loadu_ps(&y[i + 0]) + __alpha * _mm256_loadu_ps(&x[i + 0]));
15:53:55 ^
15:53:55 ../kernel/x86_64/saxpy_microk_skylakex-2.c:60:32: error: always_inline function '_mm256_loadu_ps' requires target feature 'avx', but would be inlined into function 'saxpy_kernel_16' that is compiled without support for 'avx'
15:53:55 _mm256_storeu_ps(&y[i + 0], _mm256_loadu_ps(&y[i + 0]) + __alpha * _mm256_loadu_ps(&x[i + 0]));
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 25 (20 by maintainers)
With -fopenmp it should link libomp in the end automatically - let’s see if/when we get that far. (If it starts missing omp functions at that point, I may have broken it with my recent PGI-related fixes…)
This issue is not about ARM instructions. This is about a compiler issue with clang as @martin-frbg mentioned. I’d like to see the error again with verbose to see what the issue of the compiler is. I can’t reproduce this issue without homebrew, so if you can run the failing command line with
-v, then that’ll be helpful.