Repository navigation
[Question] Implement internal OpenBLAS BLAS-like C API #5340
Description
Activity
IIRC the problem is limited to the test codes, which were copied verbatim from the all-Fortran Reference-LAPACK project, and likely does not exist for user code. The string length argument is limited to the case of single-character arguments, where LAPACK up to (IIRC) 3.8.0 assumed that the compiler would silently handle supplying the length of 1 automatically Then the gfortran developers suddenly made it mandatory and broke so much old code that they added back a fix. Nevertheless, a discussion on rigorous standard conformance had been started and led to the FORTRAN_STRLEN_END parameter in the lapack header.
I don't have time to review the existing LTO issue ticket right now, but I'm entirely unconvinced that OpenBLAS needs an additional internal API for this - unless by that you mean expanding the defines in cblas_test.h into macros that add the respective quantity of extra "1"argumentsReacted by foxtranUnfortunately, it is not limited only to the test codes:
../lapack-netlib/SRC/dgerfs.f:300:72: error: type of ‘dgemv’ does not match original declaration [-Werror=lto-type-mismatch] 300 | $ WORK( N+1 ), 1 ) | ^ ../interface/gemv.c:132:6: note: type mismatch in parameter 12 132 | void NAME(char *TRANS, blasint *M, blasint *N, | ^It still expects extra arguments for BLAS calls. There is only one example, but it is true for other BLAS routines that accept char*1 arguments.
I do not think that this is a case of the extra hidden "int" for character argument length (note that it is not a cross-language call in the original Reference-LAPACK) - rather an apparent inability of the compiler to equate the INTEGER type of the INCY argument with blasint.
- locked and limited conversation to collaborators
on Jun 29, 2025
As I see it, the current use of the Fortran ABI in the C interface presents several complications:
OpenBLAS/lapack-netlib/CBLAS/include/cblas_test.h
Lines 28 to 33 in 11ce79a
To avoid these issues—particularly with LTO—and to simplify name mangling, I’m wondering if it would make sense to implement an internal OpenBLAS BLAS-like C ABI. This ABI could act as a central internal interface, with both the Fortran bindings (with Fortran 2003 standard) and the CBLAS interface layered on top of it.
Are there any existing considerations, discussions, or objections regarding this kind of design within the OpenBLAS project?