[R-pkg-devel] R, BLAS, and FCLEN (solved)
Tomas Kalibera
tom@@@k@||ber@ @end|ng |rom gm@||@com
Fri Sep 13 11:07:04 CEST 2019
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 using r-project.org mailing list
>> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> >>
>> >> ______________________________________________
>> >> R-package-devel using r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> > ______________________________________________
>> > R-package-devel using r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
More information about the R-package-devel
mailing list