[R-pkg-devel] Single character in Fortran function and FCONE and FCLEN macros
On 9/3/19 3:07 PM, Benjamin Christoffersen wrote:
Dear Sirs, I have tried to update my 'dynamichazard' package on CRAN but I have had some issues with the '-Wlto-type-mismatch' checks. In particular, I have tried to follow "Writing R Extensions" section "Fortran character strings" and defined a C++ header file (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/Rconfig-wrap.h) with the following content
#ifndef RCONFIG_WRAP_H #define RCONFIG_WRAP_H #define USE_FC_LEN_T #include <Rconfig.h> #ifndef FCLEN #define FCLEN #endif #ifndef FCONE #define FCONE #endif #endif
I'd try following WRE on this exactly: include R_ext/BLAS.h and only after that define FCONE (if not defined) - and FCLEN if you need it as well.
which I include before including 'R_ext/BLAS.h' and 'R_ext/Lapack.h' files. I then make the following C declaration of the Fortran subroutine that causes the issue (https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/R_BLAS_LAPACK.cpp#L2-L29)
extern "C"
{
void F77_NAME(dchur)(
const char*, // UPLO
const char*, // TRANS
int*, // N
int*, // M
double*, // R
int*, // LDR
double*, // X
double*, // Z
int*, // LDZ
double*, // Y
double*, // RHO
double*, // C
double*, // S
int* // INFO,
FCLEN FCLEN
);
}
Lastly, I use the 'FCONE' macro when calling the function. The Fortran subroutine (a LINPACK subroutine) is defined in this file: https://github.com/boennecd/dynamichazard/blob/460fe74cadad5c029c4f0ffb50074139135c2166/src/BLAS_LAPACK/dchur.f#L7 I gather the above is as done in the BLAS and LAPACK header in R. Yet, I still got a mail in the CRAN submission stating that
We see
* checking whether package ?dynamichazard? can be installed ...
[207s/211s] WARNING
Found the following significant warnings:
BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ?dchur_? does
not match original declaration [-Wlto-type-mismatch]
and there's also
BLAS_LAPACK/R_BLAS_LAPACK.cpp:12:10: warning: type of ?dchur_? does not
match original declaration [-Wlto-type-mismatch]
12 | void F77_NAME(dchur)(
| ^
BLAS_LAPACK/dchur.f:7:1: note: type mismatch in parameter 15
7 | SUBROUTINE DCHUR(UPLO,TRANS,N,M,R,LDR,X,Z,LDZ,Y,RHO,C,S,INFO)
| ^
BLAS_LAPACK/dchur.f:7:1: note: type ?long int? should match type ?void?
BLAS_LAPACK/dchur.f:7:1: note: ?dchur? was previously declared here
I am not sure how to handle the issue. I am sorry if I am doing something which is obviously wrong.
I'd try debugging this with gcc -E, checking whether the FCLEN and FCONE macros work as intended. If the build process of the package seemed too complicated for that, you could also look at the disassembly for the calls, or compile with -fdump-tree-all? and look at the gfortran/gcc diagnostic files to see if the calls include the hidden 1s. The output seems to suggest that the macros have not been defined properly.||
I also got some messages about the declarations in RcppArmadillo but I gather these are upstream issues which I cannot do anything about
/home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/Lapack.h:1584:1: warning: ?dtrtri_? violates the C++ One Definition Rule [-Wodr]
1584 | F77_NAME(dtrtri)(const char* uplo, const char* diag,
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8: note: type mismatch in parameter 7
421 | void arma_fortran(arma_dtrtri)(const char* uplo, const char* diag, const blas_int* n, double* a, const blas_int* lda, blas_int* info, blas_len uplo_len, blas_len diag_len);
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8: note: type ?blas_len? should match type ?void?
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:421:8: note: ?dtrtri_? was previously declared here
/home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/BLAS.h:242:1: warning: ?dsyrk_? violates the C++ One Definition Rule [-Wodr]
242 | F77_NAME(dsyrk)(const char *uplo, const char *trans,
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_blas.hpp:110:8: note: type mismatch in parameter 11
110 | void arma_fortran(arma_dsyrk)(const char* uplo, const char* transA, const blas_int* n, const blas_int* k, const double* alpha, const double* > A, const blas_int* ldA, const double* beta, double* C, const blas_int* ldC, blas_len uplo_len, blas_len transA_len);
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_blas.hpp:110:8: note: type ?blas_len? should match type ?void?
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_blas.hpp:110:8: note: ?dsyrk_? was previously declared here
/home/Hornik/tmp/R-d-gcc-LTO/include/R_ext/Lapack.h:825:1: warning: ?dpotrf_? violates the C++ One Definition Rule [-Wodr]
825 | F77_NAME(dpotrf)(const char* uplo, const int* n,
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:467:8: note: type mismatch in parameter 6
467 | void arma_fortran(arma_dpotrf)(const char* uplo, const blas_int* n, double* a, const blas_int* lda, blas_int* info, blas_len uplo_len);
| ^
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:467:8: note: type ?blas_len? should match type ?void?
/home/Hornik/lib/R/Library/3.7/x86_64-linux-gnu/RcppArmadillo/include/armadillo_bits/def_lapack.hpp:467:8: note: ?dpotrf_? was previously declared here
installing to /home/Hornik/tmp/CRAN/dynamichazard.Rcheck/00LOCK-dynamichazard/00new/dynamichazard/libs
Yes, that seems to be an upstream problem. Best Tomas
Sincerely Yours, Benjamin Christoffersen
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel