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.
Just to keep the thread alive.
The problem is still there (using flexiblas shim library to allow run-time switching between BLAS libraries):
% xcodebuild -version
Xcode 16.2
Build version 16C5032a
% cat t2.f90
program sblas
! test some single-precision blas results.
implicit none
real :: x(2)=[3.,4.], y(2)=[1.,1.]
complex :: w(2)=[(4.,3.),(3.,4.)], z(2)=[(5.,6.),(7.,8.)]
real, external :: sdot, sdsdot, snrm2, scnrm2, sasum, scasum
complex, external :: cdotu, cdotc
character(*), parameter :: cfmt='(*(g0.4,1x))'
write(*,cfmt) 'sdot=', sdot(2,x,1,y,1), 'should be 7.000'
write(*,cfmt) 'sdsdot=', sdsdot(2,0.0,x,1,y,1), 'should be 7.000'
write(*,cfmt) 'snrm2=', snrm2(2,x,1), 'should be 5.000'
write(*,cfmt) 'scnrm2=', scnrm2(2,w,1), 'should be 7.071'
write(*,cfmt) 'sasum=', sasum(2,x,1), 'should be 7.000'
write(*,cfmt) 'scasum=', scasum(2,w,1), 'should be 14.00'
write(*,cfmt) 'cdotu=', cdotu(2,w,1,z,1), 'should be -9.000 91.00'
write(*,cfmt) 'cdotc=', cdotc(2,w,1,z,1), 'should be 91.00 5.000'
end program sblas
% gfortran t2.f90 -lflexiblas -L/opt/homebrew/lib
% flexiblas list
System-wide:
System-wide (config directory):
APPLE
library = libflexiblas_apple.dylib
comment =
NETLIB
library = libflexiblas_netlib.dylib
comment =
OPENBLASOPENMP
library = libflexiblas_openblasopenmp.dylib
...
% FLEXIBLAS=NETLIB ./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
% FLEXIBLAS=OPENBLASOPENMP ./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
% FLEXIBLAS=APPLE ./a.out
sdot= 0.000 should be 7.000
sdsdot= 0.000 should be 7.000
snrm2= 0.000 should be 5.000
scnrm2= 0.000 should be 7.071
sasum= 0.000 should be 7.000
scasum= 0.000 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
Thanks for the update. Iām still an OS version behind, so I have not tested this lately.
FYI tested on macOS Sonoma 14.6.1 + gfortran 14.2.0 and the stdlib interface:
program sblas
use stdlib_linalg_blas
! test some single-precision blas results.
implicit none(type,external)
real :: x(2)=[3.,4.], y(2)=[1.,1.]
complex :: w(2)=[(4.,3.),(3.,4.)], z(2)=[(5.,6.),(7.,8.)]
character(*), parameter :: cfmt='(*(g0.4,1x))'
write(*,cfmt) 'sdot=', dot(2,x,1,y,1), 'should be 7.000'
write(*,cfmt) 'sdsdot=', stdlib_sdsdot(2,0.0,x,1,y,1), 'should be 7.000'
write(*,cfmt) 'snrm2=', nrm2(2,x,1), 'should be 5.000'
write(*,cfmt) 'scnrm2=', nrm2(2,w,1), 'should be 7.071'
write(*,cfmt) 'sasum=', asum(2,x,1), 'should be 7.000'
write(*,cfmt) 'scasum=', asum(2,w,1), 'should be 14.00'
write(*,cfmt) 'cdotu=', dotu(2,w,1,z,1), 'should be -9.000 91.00'
write(*,cfmt) 'cdotc=', dotc(2,w,1,z,1), 'should be 91.00 5.000'
end program sblas
[dependencies]
stdlib ="*"
fpm run
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
dotu:[dependencies]
stdlib = { git="https://github.com/fortran-lang/stdlib", branch="stdlib-fpm", preprocess.cpp.macros=["STDLIB_EXTERNAL_BLAS", "STDLIB_EXTERNAL_LAPACK"] }
fpm run --flag " -framework Accelerate"
sdot= 0.000 should be 7.000
sdsdot= 7.000 should be 7.000
snrm2= 0.000 should be 5.000
scnrm2= 0.000 should be 7.071
sasum= 0.000 should be 7.000
scasum= 0.000 should be 14.00
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x1050bad2f
#1 0x1050b9d83
#2 0x198e22583
#3 0x104a71d8b
#4 0x104a71e0f
<ERROR> Execution for object " sblas_test " returned exit code 11
<ERROR> *cmd_run*:stopping due to failed executions
STOP 11