Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)
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.1000survival_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_ (, mb_497(D), nn_499(D), , z_502(D), mb_497(D),
b_503(D), , _beta, ezb_501, );
--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87,
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
dgemv_ (, mb_253(D), nn_255(D), , z_258(D), mb_253(D),
b_259(D), , _beta, ezb_257, );
--
;; 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), ,
covar_83(D), nn_68(D), beta_84(D), , , score_81(D),
, 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), ,
covar_89(D), nn_55(D), startbeta_83(D), , , score_87(D),
, 1);
--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7,
symbol_order=1772)
dgemv_ (, , , , covar_281(D), , beta_340(D), ,
, score_230, );
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
>
Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)
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_ (, mb_497(D), nn_499(D), , z_502(D), mb_497(D),
b_503(D), , _beta, ezb_501, );
--
;; Function d2_loglik_phexp (d2_loglik_phexp, funcdef_no=87,
decl_uid=4470, cgraph_uid=100, symbol_order=1108)
dgemv_ (, mb_253(D), nn_255(D), , z_258(D), mb_253(D),
b_259(D), , _beta, ezb_257, );
--
;; 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), ,
covar_83(D), nn_68(D), beta_84(D), , , score_81(D),
, 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), ,
covar_89(D), nn_55(D), startbeta_83(D), , , score_87(D),
, 1);
--
;; Function sup (sup, funcdef_no=128, decl_uid=4335, cgraph_uid=7,
symbol_order=1772)
dgemv_ (, , , , covar_281(D), , beta_340(D), ,
, score_230, );
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
#include
#ifndef FCONE
# define FCONE
#endif
#include
#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)(, 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,
>>>
Re: [R-pkg-devel] R, BLAS, and FCLEN (solved)
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
#include
#ifndef FCONE
# define FCONE
#endif
#include
#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)(, 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
Re: [R-pkg-devel] R, BLAS, and FCLEN
> 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)... 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
Re: [R-pkg-devel] R, BLAS, and FCLEN
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".) And if yes, how? 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
Re: [R-pkg-devel] R, BLAS, and FCLEN
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
Re: [R-pkg-devel] R, BLAS, and FCLEN
On 2019-08-31 21:26, Duncan Murdoch wrote: On 31/08/2019 12:47 p.m., 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. Sounds likely to be related to this item from R-devel NEWS: http://developer.r-project.org/blosxom.cgi/R-devel/2019/08/29#n2019-08-29 " Header ‘Rconfig.h’ contains the value of ‘FC_LEN_T’ deduced at installation which is used by the prototypes in headers ‘R_ext/BLAS.h’ and ‘R_ext/Lapack.h’ but to avoid extensive breakage this is only exposed when ‘USE_FC_LEN_T’ is defined. If a package's C/C++ calls to BLAS/LAPACK allow for the ‘hidden’ arguments used by most Fortran compilers to pass the lengths of Fortran character arguments, define ‘USE_FC_LEN_T’ and include ‘Rconfig.h’ (possibly _via_ ‘R.h’) before including ‘R_ext/BLAS.h’ or ‘R_ext/Lapack.h’." Thanks Duncan, but my call to dgemv is from a FORTRAN subroutine, no C is involved. It is called by .Fortran in R code. I am confused (not for the first time). Göran Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] R, BLAS, and FCLEN
On 31/08/2019 12:47 p.m., 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. Sounds likely to be related to this item from R-devel NEWS: http://developer.r-project.org/blosxom.cgi/R-devel/2019/08/29#n2019-08-29 " Header ‘Rconfig.h’ contains the value of ‘FC_LEN_T’ deduced at installation which is used by the prototypes in headers ‘R_ext/BLAS.h’ and ‘R_ext/Lapack.h’ but to avoid extensive breakage this is only exposed when ‘USE_FC_LEN_T’ is defined. If a package's C/C++ calls to BLAS/LAPACK allow for the ‘hidden’ arguments used by most Fortran compilers to pass the lengths of Fortran character arguments, define ‘USE_FC_LEN_T’ and include ‘Rconfig.h’ (possibly _via_ ‘R.h’) before including ‘R_ext/BLAS.h’ or ‘R_ext/Lapack.h’." Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] R, BLAS, and FCLEN
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'? __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
