[R-pkg-devel] please help understand an error in openMP statements

2019-09-12 Thread Marcin Jurek 
Hello everyone, I'm submitting a package to CRAN which I tested locally, on
Travis CI, R-hub and win builder. It worked no problem in all these
environments. However, after submission, I keep getting the error described
here:


https://win-builder.r-project.org/incoming_pretest/GPvecchia_0.1.0_20190912_201702/Debian/00install.out


I'm not a pro when it comes to openMP but since all previous tests
completed successfully, I thought things were alright. Could you help me
understand what's wrong and how to fix it? Source code of the package can
be found at http://github.com/katzfuss-group/GPvecchia Thanks a lot!


Marcin

[[alternative HTML version deleted]]

__
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 (solved)

2019-09-12 Thread Göran Broström 




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)(&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@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

2019-09-12 Thread 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@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