openblas 0.3.24 fails to build on aarch64-apple-darwin (all versions) in Homebrew

[fxcoudert]

openblas 0.3.24 fails to build on aarch64-apple-darwin (all versions) in Homebrew, with newly introduced error (repeated many times):

../kernel/arm64/sgemm_kernel_sve_v2x8.S:1496:5: error: instruction requires: sve or sme
    whilelt p1.s, x9, x0
    ^
../kernel/arm64/sgemm_kernel_sve_v2x8.S:1497:5: error: instruction requires: sve or sme
    cntp x15, p0, p1.s
    ^

We configure with make CC=gcc-13 FC=gfortran libs netlib shared with the following environment variables set:

    MACOSX_DEPLOYMENT_TARGET = #{MacOS.version}
    DYNAMIC_ARCH = 1
    USE_OPENMP = 1
    NUM_THREADS = 56
    TARGET = VORTEX

That was working with previous versions, but is broken now.

[martin-frbg]

I think we are correctly passing -march and -mtune here, so most likely this is an assembler error, with the build picking up the default OSX as . Do you happen to have GNU (g)as installed in your homebrew path as well, so that an appropriate setting of AS= would take care of this ? I assume the previously working versions either did not include NeoverseV1, or its SVE-using kernels

[martin-frbg]

Definitely builds as expected with full binutils under Asahi Linux - if binutils' as is actually still unsupported on OSX (I have since found out that e.g. Homebrew/homebrew-core#29177 was closed by you with that explanation) you can try adding NO_SVE=1 to your build options to get rid of all SVE targets. Alternatively it may be worth looking into (for homebrew folks) why gcc cannot pass appropriate SVE flags to AppleClang's builtin assembler

[fxcoudert]

No, GNU as is not supported on macOS.

The failing invocation is:

gcc-13 -O2 -DMAX_STACK_ALLOC=2048 -fopenmp -Wall -DF_INTERFACE_GFORT -fPIC -DDYNAMIC_ARCH -DSMP_SERVER -DUSE_OPENMP -DNO_WARMUP -DMAX_CPU_NUMBER=56 -DMAX_PARALLEL_NUMBER=1 -DBUILD_SINGLE=1 -DBUILD_DOUBLE=1 -DBUILD_COMPLEX=1 -DBUILD_COMPLEX16=1 -DVERSION=\"0.3.24\" -march=armv8.4-a+sve -mtune=neoverse-v1 -UASMNAME -UASMFNAME -UNAME -UCNAME -UCHAR_NAME -UCHAR_CNAME -DASMNAME=_dgemm_kernel_NEOVERSEV1 -DASMFNAME=_dgemm_kernel_NEOVERSEV1_ -DNAME=dgemm_kernel_NEOVERSEV1_ -DCNAME=dgemm_kernel_NEOVERSEV1 -DCHAR_NAME=\"dgemm_kernel_NEOVERSEV1_\" -DCHAR_CNAME=\"dgemm_kernel_NEOVERSEV1\" -DNO_AFFINITY -DTS=_NEOVERSEV1 -I.. -DBUILD_KERNEL -DTABLE_NAME=gotoblas_NEOVERSEV1 -DDOUBLE -UCOMPLEX -c -DDOUBLE -UCOMPLEX ../kernel/arm64/dgemm_kernel_sve_v2x8.S -o dgemm_kernel_NEOVERSEV1.o

which in turns calls the assembler as:

clang -cc1as -triple arm64-apple-macosx13.0.0 -filetype obj -main-file-name ccMnB12p.s -target-cpu apple-m1 -target-feature +v8.5a -target-feature +crc -target-feature +lse -target-feature +rdm -target-feature +crypto -target-feature +dotprod -target-feature +fp-armv8 -target-feature +neon -target-feature +fp16fml -target-feature +ras -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sm4 -target-feature +sha3 -target-feature +sha2 -target-feature +aes -I .. -fdebug-compilation-dir=/private/tmp/openblas-20230905-12149-1dh80k/OpenBLAS-0.3.24/kernel -dwarf-debug-producer "Apple clang version 14.0.3 (clang-1403.0.22.14.1)" -I .. -dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm -disable-aligned-alloc-awareness=1 -o dgemm_kernel_NEOVERSEV1.o /private/tmp/ccMnB12p.s

Adding -target-feature +sve makes the assembler pass, so probably GCC should pass it. Will look into it.

[martin-frbg]

Then it should be possible to redefine AS="as -target-feature +sve I guess ? (I only tried "as +sve" yesterday but that did not work). (Update: nope, did not work, and neither did other variations)
On the other hand, having Neoverse support in a macOS library is probably of questionable value, so maybe the target list for DYNAMIC_ARCH should exclude them - but this topic is bound to reappear when M-something gets regular SVE

[fxcoudert]

Upstream issue: iains/gcc-darwin-arm64#115
Right now, we will probably build without SVE, since Apple chips don't support it anyway.

[martin-frbg]

Pure AppleClang DYNAMIC_ARCH build does not experience any issues BTW.