What exactly are these libraries? Is -lblas part of the standard OS development system, or is it something that you installed separately? If a separate install, is the code written in C or fortran?
Is -lrefblas compiled from the fortran code from netlib?
So far, it seems that all of the various libraries that have these single-precision errors are written in C, not fortran, and the return type errors trace back to the f2c compiler and to the K&R C convention of promoting float to double.
That link does not work. If it is fortran code, could you please just look to see hows sdot(), snrm2(), etc. are declared? It would be surprising to see correct declarations in both the test program and the library that results in either incorrect results or in the segfault.
I didn’t come across this bug specifically but I did notice F2C LAPACK and Accelerate LAPACK are stuck on API 3.2.1. An interesting coincidence. I suspect reporting to Apple may not yield fruitful results, IIRC Numpy/Scipy already tried that.
Here is an update using OpenBLAS installed with Homebrew on MacOS:
$ uname -m
$ gfortran -L/opt/homebrew/opt/openblas/lib -lblas sblas.F90 && a.out
sdot= 7.000 should be 7.000
sdsdot= 7.000 should be 7.000
snrm2= 5.000 should be 5.000
scnrm2= 7.071 should be 7.071
sasum= 7.000 should be 7.000
scasum= 14.00 should be 14.00
cdotu= -9.000 91.00 should be -9.000 91.00
cdotc= 91.00 5.000 should be 91.00 5.000
Just curious why this wasn’t mentioned: f2c-converted cblas was deprecated at some point. I have read multiple threads advising against it. AFAIK, all cblas worth their salt are not f2c-converted. Has anyone tried to contact Apple?
This problem traces back to f2c source code conversions and to the K&R C convention of promoting float to double. However, it persists beyond the f2c converted code because the error had established itself at that point, and in order for new tests to pass old benchmarks, the conversion error had to be propagated. The C code for a typical blas library has preprocessor macros that allow the installation to select which convention to use, so to at least a substantial fraction of C programmers, this type conversion has become the “correct” behavior, despite the fact that the reference fortran code never had this conversion.
I did submit the error to Apple, and they did respond that they were working on the code (and presumably the associated tests). I have not installed a recent Xcode or the command line tools (which is where the -framework accelerate libraries live), so I do not know if it has been corrected since the original posts in this thread. Has anyone here compiled and run these tests with recent MacOS or Xcode software versions?