Autodetection of ILP64 can trigger Input Errors

[BrandonGroth]

In autodetection.c, LBT specifies a negative N value for input to "probe" the library whether it is using LP64 or ILP64 (autodetect_blas_interface calling isamax). However, our BLAS library by default treats negative N values as an input error and issues a STOP 1.

Other libraries like IMSL also treat negative N values as input errors and exit: https://help.imsl.com/fortran/6.0/stat/default.htm?turl=usererrors.htm

Is there any way to work around this issue?

[staticfloat]

If you have other ideas on how to more safely autodetect the library interface, I'm happy to try them out. In this case, this probing routine was chosen because it worked well with all libraries tested at the time (OpenBLAS, MKL, Accelerate and reference BLAS).

If your BLAS library is meant to be used by a variety of clients, I suggest not killing the process when the user does something wrong, but instead raising an error through whatever mechanism you like (in the case of LAPACK, there is an error return code for this purpose); it is quite disruptive to kill the process if someone calls with incorrect arguments.

It is possible we could add functionality to LBT to skip autodetection, but I am loathe to do that as the consequences for getting the interface wrong are severe; the program may segfault, or even worse, silently give wrong answers.

[imciner2]

In libblastrampoline, we currently start with the BLAS test using isamax to find the integer type, but there is also a test using the LAPACK function dpotrf, but that is only used if the backing library doesn't have an isamax symbol.

Would it be better to switch the order of these tests and instead start with the LAPACK function's test, and only execute the BLAS-based test if dpotrf isn't available? I would think the LAPACK test shouldn't cause the library to exit when we test it because we are relying on the info struct and how it has a value encoded.

[staticfloat]

Yes, I think that would be fine; we can test LAPACK first.

[imciner2]

@BrandonGroth just to check, does the library you are trying to use also expose a LAPACK implementation so the above suggestion would work (e.g., checking the LAPACK function before trying the BLAS function that errors)?