From tom@@@k@||ber@ @end|ng |rom gm@||@com  Mon May  6 10:55:29 2019
From: tom@@@k@||ber@ @end|ng |rom gm@||@com (Tomas Kalibera)
Date: Mon, 6 May 2019 10:55:29 +0200
Subject: [Rd] R problems with lapack with gfortran
In-Reply-To: <20190504164903.GB15478@troutmask.apl.washington.edu>
References: <ff60d7f9-e54d-473a-bc85-7989abc887da@tkoenig.net>
 <b24b0ef5-1f45-1a03-4153-f335e4f1f8a5@gmail.com>
 <2e68f333-1d10-02d4-3560-4b1b9d773a52@tkoenig.net>
 <6E812A6F-91B2-4412-A536-2CD672C5F4BA@xs4all.nl>
 <D521C66E-D67E-4C17-98EF-D651026561ED@gmail.com>
 <79689a6a-077c-019a-d16a-597d7b60199d@tkoenig.net>
 <20190504164903.GB15478@troutmask.apl.washington.edu>
Message-ID: <22803beb-5aeb-1c8b-4984-9fae0fd2759b@gmail.com>

On 5/4/19 6:49 PM, Steve Kargl wrote:
> On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas K?nig wrote:
>>> - figure out Fortran2003 specification for C/Fortran interoperability
>>> -- this _sounds_ like the right solution, but I don't think many
>>> understand how to use it and what is implied (in particular, will
>>> it require making changes to LAPACK itself?)
>> That would actually be fairly easy.  If you declare the subroutines
>> BIND(C), as in
>>
>>         subroutine foo(a,b) BIND(C,name="foo_")
>>         real a
>>         character*1 b
>>         end
>>
>> you will get the calling signature that you already have in your C
>> sources.
>>
>> This also has the advantage of being standards compliant, and would be
>> probably be the preferred method.
>>
> With the caveat that one may need to use the VALUE attribute to
> account for pass-by-value vs pass-by-reference.

This seems clean solution, but as I said before not easy, because 
currently the tradition is to call the Fortran interface directly from C 
(not via any C wrappers). This means one could not substitute 
LAPACK/BLAS at dynamic linking time, unless all LAPACK/BLAS 
implementations agreed on such a C interface. Now the substitution is 
based on the original Fortran interface.

In case of R, if we only used the included reference BLAS/LAPACK, we 
could do this, define our wrappers, say "c_dgemm" for "dgemm", change R 
to call via that interface, ask maintainers of all packages to change 
their code to call via their interface, and this should work with all 
Fortran 2003 compilers.

But, R is often used also with optimized BLAS/LAPACK implementations 
that can be substituted at dynamic linking time. And there we could do 
nothing at R level to help: we cannot generate such wrappers for an 
existing LAPACK/BLAS implementation (we don't have the source code, the 
compiler, etc).

It would be certainly a good thing if BLAS/LAPACK, with all 
implementation and uses, switched to a way that is compliant with 
current Fortran standard. But this should best start with the reference 
BLAS/LAPACK, continue with other BLAS/LAPACK implementations, and then 
with systems using those libraries, including R and its packages. 
Unless/before this happens, it would really be great if we could still 
use gfortran to build and use this fundamental software library.

Best
Tomas



[Rd] R problems with lapack with gfortran
Tomas Kalibera