Calling through CBLAS and not the Fortran interfaces adds an unavoidable function call overhead that is completely unnecessary. Switch over to the Fortran interfaces.

With a 64 bit mingw toolchain, attempt to build on Windows 10 is failing at link stage. The first signs of trouble in the output are messages such as:

ld.exe: i386 architecture of input file `../libopenblas_haswellp-r0.2.17.a(saxpy.obj)' is incompatible with i386:x86-64 output

(This is repeated for many many object files).

This same toolchain is able to successfully compile and link the latest openblas distribution obtained independently.

The toml contains: blas = "0.* and the command was: cargo build

A shortened version of the output can be seen here .

(Until this is resolved, is there a way to have the blas crate use the openblas artifacts I was able to compile myself independently?)

Attempting to build blas on OSX High Sierra. gcc 7 and 6 installed via homebrew.

If brew has 7 symlinked in, openblas-sys links correctly against gcc/7/libgfortran.4.dylib, but blas links against a non-existent gcc/6/libgfortran.3.dylib. I can't figure out where this is coming from.

If brew has gcc 6 symlinked in, things work as expected.

How to reproduce:

1. checkout blas
2. brew install gcc gcc6
3. brew switch gcc 7.X.X
4. cargo clean
5. cargo bench

Observed Behavior

dyld: Library not loaded: /usr/local/opt/gcc/lib/gcc/6/libgfortran.3.dylib

otool -L target/release/deps/blas-25ccd25572093ac2 shows that blas has linked against /usr/local/opt/gcc/lib/gcc/6/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0). I don't know where this path is coming from. This image does not exist.

otool -L target/release/build/openblas-src-93b86530c5caba86/out/opt/OpenBLAS/lib/libopenblas_haswellp-r0.2.20.dylib shows that openblas has correctly linked against /usr/local/opt/gcc/lib/gcc/7/libgfortran.4.dylib.

Workaround

1. brew switch gcc 6.X.X
2. cargo clean
3. cargo bench

In this case, both dylibs link against the gcc-6 libgfortran.3.dylib.

I'm trying to compile gemm example from crate page and it gives me error:

error: linking with "cc" failed: exit code: 1

 = note: Undefined symbols for architecture x86_64:
            "_dgemm_", referenced from:
                blas::dgemm::hea1ad9439b9f3ae2 in hello_cargo-e34d1495f2dabfc9.47k295ih7vv0tck5.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Some of the arguments should really be &T rather than &[T]:

pub unsafe fn zgemm(
    ...
    alpha: &[c64], 
    ...
    beta: &[c64], 
    ...
)

Hopefully fixes/improves #21 issue.

I have used the following repo: https://github.com/Reference-LAPACK/lapack as the data source, I'm not sure if it is a correct one though. However, it should be documented somewhere. :-)

I ran:

python3 c.py ../.data/lapack-master >new.result

and I got the following diff:

27,29c27,30
< /// Returns D.P. Dot product accumulated in D.P., for S.P. SX and SY DSDOT = sum
< /// for I = 0 to N-1 of SX(LX+I*INCX) * SY(LY+I*INCY), where LX = 1 if INCX .GE.
< /// 0, else LX = 1+(1-N)*INCX, and LY is defined in a similar way using INCY.
---
> /// Returns D.P. dot product accumulated in D.P., for S.P. SX and SY
> /// DSDOT = sum for I = 0 to N-1 of  SX(LX+I*INCX) * SY(LY+I*INCY),
> /// where LX = 1 if INCX .GE. 0, else LX = 1+(1-N)*INCX, and LY is
> /// defined in a similar way using INCY.
312,321c313,324
< /// CONSTRUCT THE MODIFIED GIVENS TRANSFORMATION MATRIX H WHICH ZEROS THE SECOND
< /// COMPONENT OF THE 2-VECTOR (SQRT(SD1)*SX1,SQRT(SD2)*> SY2)**T. WITH
< /// SPARAM(1)=SFLAG, H HAS ONE OF THE FOLLOWING FORMS..
< ///
< /// SFLAG=-1.E0 SFLAG=0.E0 SFLAG=1.E0 SFLAG=-2.E0
< ///
< ///  (SH11 SH12) (1.E0 SH12) (SH11 1.E0) (1.E0 0.E0) H=() () () () (SH21 SH22),
< /// (SH21 1.E0), (-1.E0 SH22), (0.E0 1.E0). LOCATIONS 2-4 OF SPARAM CONTAIN
< /// SH11,SH21,SH12, AND SH22 RESPECTIVELY. (VALUES OF 1.E0, -1.E0, OR 0.E0
< /// IMPLIED BY THE VALUE OF SPARAM(1) ARE NOT STORED IN SPARAM.)
---
> /// CONSTRUCT THE MODIFIED GIVENS TRANSFORMATION MATRIX H WHICH ZEROS
> /// THE SECOND COMPONENT OF THE 2-VECTOR  (SQRT(SD1)*SX1,SQRT(SD2)*>    SY2)**T.
> /// WITH SPARAM(1)=SFLAG, H HAS ONE OF THE FOLLOWING FORMS..
> ///
> /// SFLAG=-1.E0     SFLAG=0.E0        SFLAG=1.E0     SFLAG=-2.E0
> ///
> ///   (SH11  SH12)    (1.E0  SH12)    (SH11  1.E0)    (1.E0  0.E0)
> /// H=(          )    (          )    (          )    (          )
> ///   (SH21  SH22),   (SH21  1.E0),   (-1.E0 SH22),   (0.E0  1.E0).
> /// LOCATIONS 2-4 OF SPARAM CONTAIN SH11,SH21,SH12, AND SH22
> /// RESPECTIVELY. (VALUES OF 1.E0, -1.E0, OR 0.E0 IMPLIED BY THE
> /// VALUE OF SPARAM(1) ARE NOT STORED IN SPARAM.)
345,353c348,357
< /// SX(LX+I*INCX), I = 0 TO N-1, WHERE LX = 1 IF INCX .GE. 0, ELSE LX =
< /// (-INCX)*N, AND SIMILARLY FOR SY USING USING LY AND INCY. WITH
< /// SPARAM(1)=SFLAG, H HAS ONE OF THE FOLLOWING FORMS..
< ///
< /// SFLAG=-1.E0 SFLAG=0.E0 SFLAG=1.E0 SFLAG=-2.E0
< ///
< ///  (SH11 SH12) (1.E0 SH12) (SH11 1.E0) (1.E0 0.E0) H=() () () () (SH21 SH22),
< /// (SH21 1.E0), (-1.E0 SH22), (0.E0 1.E0). SEE SROTMG FOR A DESCRIPTION OF DATA
< /// STORAGE IN SPARAM.
---
> /// SX(LX+I*INCX), I = 0 TO N-1, WHERE LX = 1 IF INCX .GE. 0, ELSE
> /// LX = (-INCX)*N, AND SIMILARLY FOR SY USING USING LY AND INCY.
> /// WITH SPARAM(1)=SFLAG, H HAS ONE OF THE FOLLOWING FORMS..
> ///
> /// SFLAG=-1.E0     SFLAG=0.E0        SFLAG=1.E0     SFLAG=-2.E0
> ///
> ///   (SH11  SH12)    (1.E0  SH12)    (SH11  1.E0)    (1.E0  0.E0)
> /// H=(          )    (          )    (          )    (          )
> ///   (SH21  SH22),   (SH21  1.E0),   (-1.E0 SH22),   (0.E0  1.E0).
> /// SEE  SROTMG FOR A DESCRIPTION OF DATA STORAGE IN SPARAM.
369,378c373,384
< /// CONSTRUCT THE MODIFIED GIVENS TRANSFORMATION MATRIX H WHICH ZEROS THE SECOND
< /// COMPONENT OF THE 2-VECTOR (DSQRT(DD1)*DX1,DSQRT(DD2)*> DY2)**T. WITH
< /// DPARAM(1)=DFLAG, H HAS ONE OF THE FOLLOWING FORMS..
< ///
< /// DFLAG=-1.D0 DFLAG=0.D0 DFLAG=1.D0 DFLAG=-2.D0
< ///
< ///  (DH11 DH12) (1.D0 DH12) (DH11 1.D0) (1.D0 0.D0) H=() () () () (DH21 DH22),
< /// (DH21 1.D0), (-1.D0 DH22), (0.D0 1.D0). LOCATIONS 2-4 OF DPARAM CONTAIN
< /// DH11, DH21, DH12, AND DH22 RESPECTIVELY. (VALUES OF 1.D0, -1.D0, OR 0.D0
< /// IMPLIED BY THE VALUE OF DPARAM(1) ARE NOT STORED IN DPARAM.)
---
> /// CONSTRUCT THE MODIFIED GIVENS TRANSFORMATION MATRIX H WHICH ZEROS
> /// THE SECOND COMPONENT OF THE 2-VECTOR  (DSQRT(DD1)*DX1,DSQRT(DD2)*>    DY2)**T.
> /// WITH DPARAM(1)=DFLAG, H HAS ONE OF THE FOLLOWING FORMS..
> ///
> /// DFLAG=-1.D0     DFLAG=0.D0        DFLAG=1.D0     DFLAG=-2.D0
> ///
> ///   (DH11  DH12)    (1.D0  DH12)    (DH11  1.D0)    (1.D0  0.D0)
> /// H=(          )    (          )    (          )    (          )
> ///   (DH21  DH22),   (DH21  1.D0),   (-1.D0 DH22),   (0.D0  1.D0).
> /// LOCATIONS 2-4 OF DPARAM CONTAIN DH11, DH21, DH12, AND DH22
> /// RESPECTIVELY. (VALUES OF 1.D0, -1.D0, OR 0.D0 IMPLIED BY THE
> /// VALUE OF DPARAM(1) ARE NOT STORED IN DPARAM.)
402,410c408,417
< /// DX(LX+I*INCX), I = 0 TO N-1, WHERE LX = 1 IF INCX .GE. 0, ELSE LX =
< /// (-INCX)*N, AND SIMILARLY FOR SY USING LY AND INCY. WITH DPARAM(1)=DFLAG, H
< /// HAS ONE OF THE FOLLOWING FORMS..
< ///
< /// DFLAG=-1.D0 DFLAG=0.D0 DFLAG=1.D0 DFLAG=-2.D0
< ///
< ///  (DH11 DH12) (1.D0 DH12) (DH11 1.D0) (1.D0 0.D0) H=() () () () (DH21 DH22),
< /// (DH21 1.D0), (-1.D0 DH22), (0.D0 1.D0). SEE DROTMG FOR A DESCRIPTION OF DATA
< /// STORAGE IN DPARAM.
---
> /// DX(LX+I*INCX), I = 0 TO N-1, WHERE LX = 1 IF INCX .GE. 0, ELSE
> /// LX = (-INCX)*N, AND SIMILARLY FOR SY USING LY AND INCY.
> /// WITH DPARAM(1)=DFLAG, H HAS ONE OF THE FOLLOWING FORMS..
> ///
> /// DFLAG=-1.D0     DFLAG=0.D0        DFLAG=1.D0     DFLAG=-2.D0
> ///
> ///   (DH11  DH12)    (1.D0  DH12)    (DH11  1.D0)    (1.D0  0.D0)
> /// H=(          )    (          )    (          )    (          )
> ///   (DH21  DH22),   (DH21  1.D0),   (-1.D0 DH22),   (0.D0  1.D0).
> /// SEE DROTMG FOR A DESCRIPTION OF DATA STORAGE IN DPARAM.

Proof of concept for documentation generation.

Currently it only writes a summary stub, but a lot of the infrastructure is in place (parsing of routine and type from name). I would like to add some function-specific argument documentation, as well as a module level overview of how to interpret some arguments. (All incx mean the same thing, for instance.)

I also use unicode for α and ·, but I can also pull back on that.

A binary project like: Cargo.toml:

blas = "0.22.0"

src/main.rs:

use blas::*;

let (m, n, k) = (2, 4, 3);
let a = vec![
    1.0, 4.0,
    2.0, 5.0,
    3.0, 6.0,
];
let b = vec![
    1.0, 5.0,  9.0,
    2.0, 6.0, 10.0,
    3.0, 7.0, 11.0,
    4.0, 8.0, 12.0,
];
let mut c = vec![
    2.0, 7.0,
    6.0, 2.0,
    0.0, 7.0,
    4.0, 2.0,
];

unsafe {
    dgemm(b'N', b'N', m, n, k, 1.0, &a, m, &b, k, 1.0, &mut c, m);
}

assert!(
    c == vec![
        40.0,  90.0,
        50.0, 100.0,
        50.0, 120.0,
        60.0, 130.0,
    ]
);

Does not work without unspecified prior work.

Steps required to run an example should be specified else it is not a very useful example.

I have this dependency:

blas = "0.18.1"

During building this simple program (no types used de facto in the program):

extern crate blas;
use blas::c::*;

I get these errors:

error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\rpolysolve-88ff07ef5c6657b1.0.o" "-o" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\rpolysolve-88ff07ef5c6657b1.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps" "-L" "C:/Users/steve/Dropbox/Projects/rpolysolve/target/debug/build/openblas-src-d878051769a2d73f/out\\opt/OpenBLAS/lib" "-L" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libblas-b4aae95537d012fb.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libblas_sys-e0d39b2df28e83ce.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libopenblas_src-f69049297a7464c8.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libnum_complex-f6dcb9467a42a2a8.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\liblibc-c8ae433ae4a960ed.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libnum_traits-f34085513d19d5a6.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-5a958d157a8d8d98.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-14e8bb7ca07ebf2c.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-a4bc20050f473f79.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-892bd58ec617c3bd.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librand-ce86047000b56785.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcollections-b8b9a576d130e244.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-b9c9173c47c20c41.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc_system-141f235246f01712.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd_unicode-9fbe5d3bbc85c563.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-3a6338503b91076c.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-e9e280acad4314a4.rlib" "-Wl,-Bdynamic" "-l" "gfortran" "-l" "openblas" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-Wl,-Bstatic" "-l" "gcc_eh" "-l" "pthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: ld: cannot find -lgfortran
          C:/Users/steve/Dropbox/Projects/rpolysolve/target/debug/build/openblas-src-d878051769a2d73f/out\opt/OpenBLAS/lib/libopenblas.a: file not recognized: File format not recognized

My active toolchain is stable-x86_64-pc-windows-gnu. I want to keep it, because this is the only working approach for debug, which I've found (msvc toolchain doesn't allow to run dgb and thus debug in CLion).

What can I do? Are there any other connectors between rust and blas? More scpecially I need to call dsyev_. May be there are any other known stable methods of calculating real eigen values in rust?

The issue about complex is a bit tricky. In practice there is no problem at all; its memory layout is compatible with C complex, so using &num::Complex<f64> where a pointer to c complex is expected, is completely fine.

https://github.com/rust-num/num/issues/79

However it is our common interest that the linked issue is resolved in some way.

Currently if the user specifies invalid size parameters to blas routines, buffer overruns of the input slices may result within the foreign blas code.

It would be easy to check passed size arguments against slice sizes in many if not all of the wrapper blas functions prior to the foreign call. The performance cost should be negligible, much less than having even one additional row in an input matrix.

The checks would be only that the input buffer bounds are not overrun, it would not be a requirement that input sizes (or products of two of them) exactly match slice lengths, so full flexibility of the blas routines would be maintained.

The following functions are poorly formated due to the poor formatting in the original code:

• dsdot,
• srotmg,
• srotm,
• drotmg, and
• drotm.

The documentation script should be adjusted in order to account for those cases.