[Question] Implement internal OpenBLAS BLAS-like C API

As I see it, the current use of the Fortran ABI in the C interface presents several complications:

Passing strings between C and Fortran requires additional arguments, which are missing in standard C ABI declarations. This has already caused issues, such as in the LTO-related bug #4128.
Different Fortran compilers use different ABIs for string passing, adding to the complexity.

Fortran name mangling varies across platforms, leading to duplicated or enumerated symbols in headers, as seen here:

OpenBLAS/lapack-netlib/CBLAS/include/cblas_test.h

Lines 28 to 33 in 11ce79a

    
           #define F77_srotg 		F77_GLOBAL(srotgtest,SROTGTEST) 
        
           #define F77_srotmg 		F77_GLOBAL(srotmgtest,SROTMGTEST) 
        
           #define F77_srot 		F77_GLOBAL(srottest,SROTTEST) 
        
           #define F77_srotm 		F77_GLOBAL(srotmtest,SROTMTEST) 
        
           #define F77_drotg 		F77_GLOBAL(drotgtest,DROTGTEST) 
        
           #define F77_drotmg 		F77_GLOBAL(drotmgtest,DROTMGTEST)

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?

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"arguments

Unfortunately, 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.

Navigation Menu

Repository navigation

[Question] Implement internal OpenBLAS BLAS-like C API #5340

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	#define F77_srotg F77_GLOBAL(srotgtest,SROTGTEST)
	#define F77_srotmg F77_GLOBAL(srotmgtest,SROTMGTEST)
	#define F77_srot F77_GLOBAL(srottest,SROTTEST)
	#define F77_srotm F77_GLOBAL(srotmtest,SROTMTEST)
	#define F77_drotg F77_GLOBAL(drotgtest,DROTGTEST)
	#define F77_drotmg F77_GLOBAL(drotmgtest,DROTMGTEST)

[Question] Implement internal OpenBLAS BLAS-like C API #5340

Description

Activity

martin-frbg commented on Jun 25, 2025

foxtran commented on Jun 28, 2025

martin-frbg commented on Jun 29, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions