Dear Tomas,
your explanation matches exactly my expectation, but not my experience.
I uploaded (to CRAN) version 2.7.5 yesterday, and there I use, in the
Fortran function gmlfun, directly called by .Fortran:
call cdgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
& score, ione)
that is, the C wrapper of dgemv (my home-brew)
No warnings from R-devel CMD check --as-cran, and when installed it runs
fine.
However, if I change that call to
call dgemv(trans, nn, antcov, one, covar, nn, beta, ione, one,
& score, ione)
that is, a direct call to the Fortran subroutine dgemv, I get, from
R-devel CMD check --as-cran,
gmlfun.f:224:1: warning: type of ‘dgemv’ does not match original
declaration [-Wlto-type-mismatch]
& score, ione)
^
/home/gobr0002/R/src/R-devel/include/R_ext/BLAS.h:107:1: note: type
mismatch in parameter 12
F77_NAME(dgemv)(const char *trans, const int *m, const int *n,
^
and when I install and run, I get error:
> library(eha)
Loading required package: survival
> fit <- coxreg(Surv(enter, exit, event) ~ ses, data = mort, geometric
= TRUE)
Error in geome.fit(X, Y, rs, strats, offset, init, max.survs, method, :
BLAS/LAPACK routine 'DGEMV ' gave error code -1
>
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 19.04
...
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
...
Other attached packages:
[1] eha_2.7.5.1000 survival_2.44-1.1
-------------
To summarize: The calls from C code are fixed and work fine. Direct call
from fortran "level 1" gives error, from "level 2" is fine. "level 1" is
fortran code directly called by .Fortran, "level 2" is fortran code
called from fortran code called by .Fortran.
This was done with
R Under development (unstable) (2019-08-31 r77115). I could try a more
recent version of R-devel.
About a 'small reproducible example': It is not that easy to shrink the
eha package to include only the relevant fortran code, since there are
subtle interdependencies in the package code. It would take a
considerable amount of time (for me) to create that package.
I can make eha_2.7.5.tar.gz available, but it was sent in to CRAN yesterday.
Göran
On 2019-09-13 11:07, Tomas Kalibera wrote:
Dear Göran,
I can reproduce the problem with eha version 2.6.0. The reason for the
type mismatch, and hence the LTO warning, is _not_ the calls to dgemv
from Fortran code, but the calls to dgemv from the C code from the other
source files in your package. There is no need to go through wrappers
when calling dgemv from Fortran (as long as both modules are compiled
with the same compiler, or with compatible compilers).
When you fix all the calls to dgemv in your C source files to use
"FCONE", as documented in WRE, the warning about the call to dgemv from
geomsup.f will go away (yes, the warnings from the LTO linker/compiler
are confusing). There is no need for creating any wrappers for
BLAS/LAPACK calls.
One can check that the generated calls from the Fortran are correct e.g.
via compiling with -fdump-tree-all and then dumping
$ egrep -e '(^;;)|(dgemv)' eha.so.ltrans0.232t.optimized | grep dgemv -B1
(the file name above will depend on the exact version of your compiler)
;; Function d2_loglik_ph (d2_loglik_ph, funcdef_no=77, decl_uid=4474,
cgraph_uid=103, symbol_order=990)
dgemv_ (&trans, mb_497(D), nn_499(D), &alf, z_502(D), mb_497(D),
b_503(D), &one, &Rf_beta, ezb_501, &one);
--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87,
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
dgemv_ (&trans, mb_253(D), nn_255(D), &alf, z_258(D), mb_253(D),
b_259(D), &one, &Rf_beta, ezb_257, &one);
--
;; Function gmlfun (gmlfun_, funcdef_no=98, decl_uid=4484,
cgraph_uid=108, symbol_order=874)
dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_68(D), antcov_63(D), &C.7966,
covar_83(D), nn_68(D), beta_84(D), &C.7965, &C.7964, score_81(D),
&C.7963, 1);
--
;; Function geomsup (geomsup_, funcdef_no=116, decl_uid=4498,
cgraph_uid=117, symbol_order=823)
dgemv_ (&"N"[1]{lb: 1 sz: 1}, nn_55(D), antcov_51(D), &C.9626,
covar_89(D), nn_55(D), startbeta_83(D), &C.9625, &C.9624, score_87(D),
&C.9623, 1);
--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7,
symbol_order=1772)
dgemv_ (&trans, &nn, &p, &one, covar_281(D), &nn, beta_340(D), &ione,
&one, score_230, &ione);
You can see that the calls to dgemv from gmlfun and geomsup are fine
(from Fortran code), the other are bad (from C code). Indeed, one would
have found out also by creating a minimal reproducible example - it is
always useful, even when not attempting to report a bug.
Best
Tomas
On 9/13/19 12:07 AM, Göran Broström wrote:
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
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
