-
Notifications
You must be signed in to change notification settings - Fork 480
Description
Hello,
since it's inception CBLAS seems to have assumed it's Ok to pass a length=1 string to the Fortran BLAS without passing a hidden string length argument. And the newer LAPACKE seems to have followed suit.
While this has worked (apparently adequately?) for several decades, in light of increasingly sophisticated compiler optimizations, for instance interprocedural or link-time optimizations, such sins are unfortunately coming back to haunt us.
The R developers noticed something fishy in their LAPACK interface with recent versions of GFortran. They don't use LAPACKE, but the issue is due to them also omitting the string length argument. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 and links to mailing list threads therein for details.
While some workarounds exist, they aren't really bulletproof, and the proper and robust fix is to change the interfaces so that they match between the caller and the callee. The problem is that there is no "standard" Fortran ABI, and different compilers use different ways to pass the hidden string length information. A couple of ways around this:
-
Use the Fortran 2003 ISO_C_BINDING feature to create a C ABI compatible wrapper routine that can then call the actual Fortran implementation. This would be robust, but the downside is that this approach requires a Fortran compiler with the ISO_C_BINDING feature (which is all(?) actively maintained compilers these days, but if you want to retain support for old compilers this could be a problem). Also there would be an extra layer of indirection, e.g. instead of "cblas_foo -> foo" it would be "cblas_foo -> cblas_icb_foo -> foo", although it should be possible for the compiler to inline the extra wrapper.
-
Use knowledge of compiler-specific argument passing conventions and macro magic. This is somewhat brittle, and requires fiddling with build machinery and macros, but doesn't need ISO_C_BINDING, and avoids the extra wrapper routines.