Repository navigation
float32 SSYRK wrong on ARM64 VORTEXM4 (RowMajor, Upper, NoTrans) #5873
Description
The float32 VORTEXM4 SSYRK kernel computes incorrect results.
Here is a repo with a vibe coded minimal reproducer:
https://github.com/ogrisel/repro_pypi_numpy_openblas_float32_matmul/tree/main/openblas_ssyrk_repro
On my M4 laptop I get:
$ ./repro_ssyrk testdata/A.bin .venv/lib/python3.13/site-packages/numpy/.dylibs/libscipy_openblas64_.dylib
OpenBLAS repro: float32 SSYRK vs SGEMM for A @ A.T
matrix: testdata/A.bin (300 x 672, row-major float32)
BLAS: .venv/lib/python3.13/site-packages/numpy/.dylibs/libscipy_openblas64_.dylib
SSYRK (RowMajor, Upper, NoTrans, n=300, k=672, lda=672, ldc=300):
max = 0.000000 expected ~185.7 => FAIL
SGEMM control (RowMajor, NoTrans, Trans, m=300, n=300, k=672):
max = 185.703522 expected ~185.7 => OK
Naive float64 reference GEMM:
max = 185.703644
Reproduced: SSYRK broken, SGEMM OK (matches NumPy issue).
while I get the expected results when forcing the NEOVERSEN1 kernel instead:
$ OPENBLAS_CORETYPE=NEOVERSEN1 ./repro_ssyrk testdata/A.bin .venv/lib/python3.13/site-packages/numpy/.dylibs/libscipy_openblas64_.dylib
OpenBLAS repro: float32 SSYRK vs SGEMM for A @ A.T
matrix: testdata/A.bin (300 x 672, row-major float32)
BLAS: .venv/lib/python3.13/site-packages/numpy/.dylibs/libscipy_openblas64_.dylib
OPENBLAS_CORETYPE=NEOVERSEN1
SSYRK (RowMajor, Upper, NoTrans, n=300, k=672, lda=672, ldc=300):
max = 185.703613 expected ~185.7 => OK
SGEMM control (RowMajor, NoTrans, Trans, m=300, n=300, k=672):
max = 185.703613 expected ~185.7 => OK
Naive float64 reference GEMM:
max = 185.703644
Both paths OK on this host.
Originally reported at: numpy/numpy#31776
Activity
jschueller commentedon Jul 2, 2026
can you test #5874 ?
martin-frbg commentedon Jul 2, 2026
Curiously the reproducer already passes for me when I replace the libscipy_openblas from the wheel with one built (using LLVM 22.1.6) from the current develop branch. Two bugs cancelling each other somewhere ?
martin-frbg commentedon Jul 2, 2026
...but all I can test on is an M4 mini, and the PR does not appear to hurt either. So perhaps ZA indexing gets remapped by firmware on small systems, and the original SME SSYRK PR happened to be developed on a Mac mini too ?
ogrisel commentedon Jul 3, 2026
Have you tried to force the
VORTEXM4core type?martin-frbg commentedon Jul 3, 2026
I've tried both a dedicated build on target, and a DYNAMIC_ARCH build where setting OPENBLAS_VERSBOSE=2 at runtime confirms it is using VORTEXM4. But maybe this really is a problem that does not manifest itself on a Mac mini ?
I'll look into what's (still or again) wrong with compiler version handling - I assume you're using the AppleClang from the xcode package rather than a homebrew-installed LLVM-clang ?
Fix ZA tile slice indices in ssyrk SME direct kernel
ogrisel commentedon Jul 3, 2026
Good question, let me check. Unfortunately, I killed the terminal where I checked the repro, but I think it was the system clang.