[R-pkg-devel] R, BLAS, and FCLEN

[Martin Maechler]

>>>>> 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 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