Skip to content

Use Accelerate for BLAS/LAPACK on Apple Silicon - #75

Merged
krystophny merged 1 commit into
mainfrom
fix/macos-arm64-accelerate
Oct 23, 2026
Merged

krystophny merged 1 commit into
mainfrom
fix/macos-arm64-accelerate

Conversation

@krystophny

Copy link
Copy Markdown
Member

On Apple Silicon, activate.sh pointed builds at Homebrew OpenBLAS. That library uses LLVM libomp, while gfortran codes use libgomp, so threaded Fortran codes load two OpenMP runtimes. With OpenBLAS 0.3.31-0.3.33 this gave silently wrong DGEMM results from inside gfortran !$omp loops (OpenMathLib/OpenBLAS#5825, fixed in 0.3.34), first seen as thread-count-dependent results in GVEC.

This switches BLAS_LIBRARIES/LAPACK_LIBRARIES to the Accelerate framework and sets BLA_VENDOR=Apple. Intel Macs and Linux are unchanged.

Checked locally: a CMake gfortran OpenMP build of the DGEMM reproducer with these settings links only Accelerate and libgomp and agrees across 1, 4 and 8 threads (relative error 0). Existing build trees keep their cached BLAS until reconfigured.

Chris&AI

Homebrew OpenBLAS is built against LLVM libomp while gfortran uses libgomp,
so one process carries two OpenMP runtimes. OpenBLAS 0.3.31-0.3.33 returned
wrong DGEMM results when called from gfortran OpenMP threads
(OpenMathLib/OpenBLAS#5825, fixed in 0.3.34). Accelerate keeps a single
OpenMP runtime. A gfortran OpenMP DGEMM reproducer built with these
settings agrees across 1, 4 and 8 threads.
@krystophny
krystophny added this pull request to the merge queue Oct 23, 2026
Merged via the queue into main with commit 084273f Oct 23, 2026
1 check passed
@krystophny
krystophny deleted the fix/macos-arm64-accelerate branch October 23, 2026 08:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant