[R-pkg-devel] Single character in Fortran function and FCONE and FCLEN macros

Benjamin Christoffersen boennecd @end|ng |rom gm@||@com
Fri Sep 6 13:46:29 CEST 2019


> 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.
That is an embarrassing error. I will try to do exactly as is written in WRE.

> 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.
Thanks mentioning these options.

Best regards,
Benjamin


Den tir. 3. sep. 2019 kl. 15.37 skrev Tomas Kalibera <tomas.kalibera using gmail.com>:
>
> 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>



More information about the R-package-devel mailing list