On 2019-09-12 09:13, Martin Maechler wrote:
Göran Broström
on Wed, 11 Sep 2019 13:36:40 +0200 writes:
> A followup question: Is it possible to call a BLAS/LAPACK
subroutine,
> where one parameter is character, from FORTRAN (77) code
called by
> .Fortran? (No problem "in the past".)
[as there wasn't a reply till now : ]
Yes, that should continue to be possible.
> And if yes, how?
I'm sorry I don't know (and currently lack the time to try to find
out)...
I solved it by writing a C wrapper (for the BLAS subroutine dgemv)
cdgemv:
#define USE_FC_LEN_T
#include <Rconfig.h>
#include <R_ext/BLAS.h>
#ifndef FCONE
# define FCONE
#endif
#include <R.h>
#include "cdgemv.h"
void F77_SUB(cdgemv)(const int *trans, const int *m, const int *n,
const double *alpha, const double *a,
const int *lda,
const double *x, const int *incx,
const double *beta,
double *y, const int *incy){
char trams;
if (*trans == 1){
trams = 'N';
F77_CALL(dgemv)(&trams, m, n, alpha, a, lda, x, incx, beta, y,
incy FCONE);
}else
Rprintf("trans has wrong value\n");
}
}
which I call from Fortran. Curiously, a Fortran wrapper also seems to
work.
G,
Martin
> Documentation describes calls from C to Fortran and
> vice versa, but not this situation (AFAICS).
> Yes, I know that .Fortran is not well seen these days, but my
fortran
> code is ancient, from the before-R era, and I would like to
leave it as-is.
> G,
> Den 2019-09-01 kl. 21:46, skrev Göran Broström:
>>
>>
>> On 2019-08-31 18:47, Göran Broström wrote:
>>> I'm having difficulties updating my package eha: When I run
standard
>>> checks 'at home' everything is fine, but 'CRAN-submissions'
reports
>>> (among other things):
>>>
>>> geomsup.f:324:9: warning: type of ‘dgemv’ does not match
original
>>> declaration [-Wlto-type-mismatch]
>>> 324 | & one, score, ione)
>>> | ^
>>> /home/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:107:1: note: type
mismatch
>>> in parameter 12
>>> 107 | F77_NAME(dgemv)(const char *trans, const int *m,
const int *n,
>>> | ^
>>>
>>> This is odd since the LAPACK subroutine dgemv takes only 11
>>> parameters. However, in include/R_ext/BLAS.h we have
>>>
>>> F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
>>> const double *alpha, const double *a, const int *lda,
>>> const double *x, const int *incx, const double *beta,
>>> double *y, const int *incy FCLEN);
>>>
>>> with a 12th parameter FCLEN?? How am I supposed to fix this,
and what
>>> the ... is FCLEN? googling leads to nothing useful (for me).
It seems
>>> as if R is redefining some standard LAPACK routines.
>>>
>>> Also a note I do not understand (in this context):
>>>
>>> note: type ‘void’ should match type ‘long int’
>>>
>>> Any help is much appreciated.
>>>
>>> Best, Göran
>>>
>>> PS. How can I trigger these Warnings 'at home'?
>>
>> See https://www.stats.ox.ac.uk/pub/bdr/LTO/README.txt (thanks
to Uwe
>> Ligges).
>>
>> Another relevant document seems to be (2019-05-15):
>>
>>
https://developer.r-project.org/Blog/public/2019/05/15/gfortran-issues-with-lapack/index.html
>>
>>
>> First sentence:
>> "Recent version of the GNU Fortran compiler (7, 8, 9) include
>> optimizations that break interoperability between C and
Fortran code
>> with BLAS/LAPACK."
>>
>> And later:
>> "For the time being, everyone should use
-fno-optimize-sibling-calls
>> with GFortran version 7 and newer."
>>
>> G,
>>
>>> ______________________________________________
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
