ENH: build fallback lapack_lite with 64-bit integers on 64-bit platforms#15218
ENH: build fallback lapack_lite with 64-bit integers on 64-bit platforms#15218charris merged 5 commits intonumpy:masterfrom
Conversation
Build the lapack fallback library (used when no LAPACK installed) with 64-bit integer size when building on a 64-bit platform.
charris
added
01 - Enhancement
09 - Backport-Candidate
|
Hmm, I originally marked this for backport but changed my mind as it might lead to confusion going forward to change this in 1.18.1. It is probably a bit riskier as well. @pv If you would like to see this in 1.18 let me know. It would be good if the version used was available in |
Make numpy.__config__.show() to print information about the fallback lapack_lite library when it is used.
|
I agree this doesn't need backport. Added the information to |
| typedef struct { real r, i; } complex; | ||
| typedef struct { doublereal r, i; } doublecomplex; | ||
| typedef int logical; | ||
| typedef CBLAS_INT logical; |
There was a problem hiding this comment.
I'm a little surprised this is the case, but I assume it comes down to the definitions of functions from cblas?
There was a problem hiding this comment.
npy_cblas.h does not contain functions that have logical arguments, and numpy.linalg does not use such functions either. (LAPACK does however contain such functions, but the point is probably moot.)
I think there is no standard for size of logical in Fortran. For gfortran, -fdefault-integer-8 implies also LOGICAL is 8 bytes, and I think that's also true for ifort.
The "canonical" C API LAPACKE defines lapack_logical as lapack_int, also in its ILP64 configuration, https://github.com/Reference-LAPACK/lapack/blob/f24797e40e44c6d98ea7fa4e36bd1ec6c02c95e5/LAPACKE/include/lapacke_config.h#L46-L56 so I think precedent says it should be like that also here (even though it generally does not matter as the ABI is not exposed).
| extern integer s_rdfe(cilist *); | ||
| extern integer s_rdue(cilist *); | ||
| extern integer s_rnge(char *, integer, char *, integer); | ||
| extern int s_rnge(char *, int, char *, int); |
There was a problem hiding this comment.
Any idea what defines this function? Perhaps the definition should change. (f2c.c?)
There was a problem hiding this comment.
The definition is like this in f2c.c (i.e. int instead of integer), and the function is unused.
|
A release note seems appropriate for this. |
|
Thanks Pauli. |
|
I realize unfortunately only now the situation is here the same as with openblas64 without symbol suffix, so corner-case stuff like Numpy could also consider using symbol hiding on Linux (which I think would also fix this), along e.g. the lines Scipy has been using for many years now: Probably needs finding out first if there's some common software that uses symbols directly from the |
3 participants
Build the lapack fallback library (used when no LAPACK installed) with 64-bit integer size when building on a 64-bit platform.
Add an indicator flag in
numpy.linalg.lapack_liteshowing whether it was built with 64-bit integers, and use that in the tests (instead of checking whether numpy was linked with external 64-bit BLAS).Closes: gh-5906
Note that the 64-bit mode is turned on unconditionally, regardless of the
NPY_USE_BLAS_ILP64setting. I think this is generally OK --- this stuff is fully internal to Numpy, and the change is not visible outside, and the environment flag is anyway only used as a way for the user to control which BLAS library Numpy links against.NB. the one
s_rngeis unused function (error reporting for f2c bounds checking, which is turned off here. Just corrected its prototype here to matchf2c.c.).