4 ms·
One other nice benefit to this project is determining name mangling schemes when linking to other Fortran projects using a pure LLVM toolchain. Say we want to
by kxyvr 9y ago
One other nice benefit to this project is determining name mangling schemes when linking to other Fortran projects using a pure LLVM toolchain.
Say we want to use BLAS and LAPACK in a C/C++ project that uses clang as the compiler. All we have to do is write the appropriate prototype for the LAPACK function in C and then link to BLAS/LAPACK. That said, there are four different name mangling schemes that the BLAS/LAPACK could use, which are combinations of upper case or with trailing underscores, e.g. gemm, GEMM, gemm_, and GEMM_. Both Autotools and CMake will determine the mangling scheme for us, but they need a Fortran compiler to determine that. Right now, that's almost always GFortran. With this project, it could ostensibly be Flang, which would eliminate the need for GCC to determine the mangling if a pure LLVM toolchain is desired.
- jabl 9y agoModern LAPACK already comes with an official C binding, LAPACKE: http://www.netlib.org/lapack/lapacke.html http://www.netlib.org/lapack/lapacke.html The C ABI is pretty stable, so if you're using LAPACKE you shouldn't need to worry about which Fortran compiler was used to compile LAPACK. Other than that, AFAIK the most common name mangling these days is lowercasing + trailing underscore. That being said, for "modern Fortran" with modules, OOP etc. the issues are vastly more complex and AFAICS there is no commonly agreed upon ABI.
- bonzini 9y agoDo you mean a proprietary toolchain?