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.
Dear Ron Shepard,
To my understanding the code is written in Fortran. The installed library
has passed all the recommended tests, as set by LAPACK mainainers:
https://fossies.org/linux/misc/lapack-3.9.0.tar.gz
The installation instructions for OSX 10.9, up to macOS Mojave, are here:
I see the same results on Cygwin as well (with a newer gfortran-10).
To create the static libraries, one has to download the latest tarball:
pc-rules-2021-03-05.tar.bz2
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.
Hello,
File gone - probably newer version of requested archive available:
https://fossies.org/linux/misc/lapack-3.10.1.tar.gz/
In alternative, one can find the exact version in macports:
http://distfiles.macports.org/lapack/lapack-3.9.0.tar.gz
or one can download it from LAPACK — Linear Algebra PACKage
Once this exact version is in folder Downloads the outdated
PC script will not attempt to download it again. To see the build
instructions one can type:
./port details lapack NODEPS=X
If you have GNU C, FORTRAN in /usr/local/bin/ this might work:
./port archive lapack NODEPS=X
With good luck one may find a package at /tmp/archives
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
arm64
$ 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
So all is good with a recent OpenBLAS install.
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?
The snrm2 bug hits again: rust - snrm2 calculation instability for single-precision floats on Accelerate - Stack Overflow
The answer is worth a +200 reputation bounty if you can answer in the next hour.