Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C -> Fortran ABI issues in CBLAS & LAPACKE #339

Closed
jabl opened this issue May 8, 2019 · 6 comments
Closed

C -> Fortran ABI issues in CBLAS & LAPACKE #339

jabl opened this issue May 8, 2019 · 6 comments

Comments

@jabl
Copy link

jabl commented May 8, 2019

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:

  1. 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.

  2. 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.

@jabl
Copy link
Author

jabl commented Jun 20, 2019

Having thought about this issue for a while, there's also the option

  1. Rewrite CBLAS and LAPACKE in Fortran using BIND(C). That would avoid the extra wrapper issue with option 1. and the fragility of option 2.

@weslleyspereira
Copy link
Collaborator

#515 closed the CBLAS part. We still need to change LAPACKE/include/lapack.h to solve this issue.

@eshpc
Copy link
Contributor

eshpc commented May 10, 2021

I've had reason to add the LAPACK_FORTRAN_STRLEN_END info to some of the interfaces in a local copy of LAPACKE/include/lapack.h. I'm happy to go ahead and add it to all of them, but I'd like to check that I'm not duplicating work someone else has already done.

@weslleyspereira
Copy link
Collaborator

Hi @eshpc. As far as I know, nobody is working on that, and it would certainly be good to have these ifdefs on LAPACKE too. Thanks!

@eshpc
Copy link
Contributor

eshpc commented May 10, 2021

@weslleyspereira OK, thanks for the info. I'll submit a PR when it is ready.

@weslleyspereira
Copy link
Collaborator

weslleyspereira commented May 24, 2023

Solved by #515 and #561. Please, let me know if there is still something to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants