[R-pkg-devel] R, BLAS, and FCLEN (solved, really!)
On 2019-09-13 12:34, G?ran Brostr?m wrote:
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, ?^
This error message was triggered by my mistake in the change from cdgemv to dgemv: I forgot to change 'trans' back from type INTEGER to CHARACTER. Our final conclusion (for now) is then: Yes, you can call BLAS subroutines directly from Fortran code, even in packages! Many thanks to Tomas! Excuse my confusion, G,
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 at r-project.org mailing list ???? >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel ???? >> ???? >> ______________________________________________ ???? >> R-package-devel at r-project.org mailing list ???? >> https://stat.ethz.ch/mailman/listinfo/r-package-devel ???? > ______________________________________________ ???? > R-package-devel at r-project.org mailing list ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel