Skip to content

[R-pkg-devel] warning: type of ‘zhpevx_’ does not match original declaration [-Wlto-type-mismatch]

9 messages · Ivan Krylov, Pierre Lafaye de Micheaux, William Dunlap +1 more

Original
Pierre Lafaye de Micheaux
# 
Dear all,

The problem:
I struggle to solve a WARNING that is shown on the CRAN system but not on my side when I use "R-devel check --as-cran IndependenceTests". This seems to be related to the declaration of a LAPACK Fortran subroutine (zhpevx) that I call from C.

I could not find any hint on Google allowing me to solve the issue. I read the following sections of the "Writing R Extensions" manual (but could not understand how to solve the problem):

  *   4.5 Using Link Time Optimization
  *   6.6 Calling C from Fortran and vice versa

Maybe the solution is obvious, but not to me.

The warning shown on CRAN is:
checking whether package ?IndependenceTests? can be installed ...
[11s/11s] WARNING
Found the following significant warnings:
    myzhpevx.cpp:13:23: warning: type of ?zhpevx_? does not match original declaration [-Wlto-type-mismatch]

Other feedback I received from the CRAN team:
Professor Brian Ripley suggested the two pieces of advice below (which I believe to have followed):

  *   For registering/interfacing Fortran calls,
       gfortran -c -fc-prototypes-external
is the best way to extract a prototype (with gfortran >= 9.2).  If this
includes int_least32_t, see the comment below on Fortran-LOGICAL.
hint).
  *
 Fortran subroutines correspond to C void functions

What is the current state of my source code:
I have a Fortran subroutine (defined in the file src/zhpevx.f at line 232):
      SUBROUTINE zhpevx( JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU,
     $     abstol, m, w, z, ldz, work, rwork, iwork,
     $     ifail, info )

This subroutine is declared (in file myzhpevx.cpp at line 13) as follows:
          void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
      const int *n, Rcomplex *ap, const double *vl,
      const double *vu, const int *il, const int *iu,
      const double *abstol, int *m, double *w,
      Rcomplex *z, const int *ldz, Rcomplex *work, double *rwork,
      int *iwork, int *ifail, int *info,
      FC_LEN_T jobz_len,  FC_LEN_T range_len,  FC_LEN_T uplo_len);

Source package can be downloaded here:
http://biostatisticien.eu/IndependenceTests_0.5.tar.gz

My system:
Linux Debian 10 Buster
Last version of R-devel

Many thanks in advance for your help.

Best regards,

Pierre Lafaye de Micheaux

Associate Professor UNSW Sydney
Co-op Academic Coordinator for Data Science & Decisions and Advanced Maths

Tel.: (00.[+612]) 9385 7029                                      School of Mathematics and Statistics
http://web.maths.unsw.edu.au/~lafaye/            UNSW Sydney, NSW 2052, AUSTRALIA

Beginning of all science is the surprise that things are what they are (Aristotle). C'est par l'exemple et la coh?rence qu'on arrive ? convaincre (P. Rabhi).
3 days later
Ivan Krylov
# 
On Fri, 3 Jul 2020 00:15:27 +0000
Pierre Lafaye de Micheaux <lafaye at unsw.edu.au> wrote:

            

      
      
      
    

        
I managed to reproduce the warning on R-devel r78607 built with
--enable-lto using gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1):

myzhpevx.cpp:13:16: warning: type of ?zhpevx_? does not match original declaration [-Wlto-type-mismatch]
           void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
                ^
zhpevx.f:232:7: note: type mismatch in parameter 20
       SUBROUTINE zhpevx( JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU,
       ^
zhpevx.f:232:7: note: type ?int? should match type ?size_t?
/usr/lib/gcc/x86_64-linux-gnu/6/include/stddef.h:216:23: note: the incompatible type is defined here
 typedef __SIZE_TYPE__ size_t;
                       ^
zhpevx.f:232:7: note: ?zhpevx? was previously declared here
       SUBROUTINE zhpevx( JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU,
       ^

Do you have access to the notes produced by the compiler in addition
to the warnings? Do they spell the same difference?

If yes, the warning is likely to be safe to ignore. m4/R.m4 notes that,
while gfortran < 8 uses int instead of size_t for hidden size arguments,
it doesn't make a practical difference.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Pierre Lafaye de Micheaux
    

    

      
      #
    

  


  

      
Dear Ivan,

Thank you very much for your response.

I do not have more information than the one I gave in my previous email. (And on top of that, the computer I was using with Debian SID, a recent version of gfortran and the last version of R-devel, just broke.)

My problem is that the CRAN team won't accept to publish my package until this WARNING problem is solved. And because I am unable to observe the warning on my side (I could not with the desktop that just broke, and I still can't with my current laptop with Debian 10), I have no clue on how to suppress this warning.

Thank you in advance for any other advice.

Best regards,
Pierre

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
Have you tried what is recommended in
https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
?

<quote>
For arguments of CHARACTER type, the character length is passed as a
hidden argument at the end of the argument list. For deferred-length
strings, the value is passed by reference, otherwise by value. The
character length has the C type size_t (or INTEGER(kind=C_SIZE_T) in
Fortran). Note that this is different to older versions of the GNU
Fortran compiler, where the type of the hidden character length
argument was a C int. In order to retain compatibility with older
versions, one can e.g. for the following Fortran procedure

subroutine fstrlen (s, a)
   character(len=*) :: s
   integer :: a
   print*, len(s)
end subroutine fstrlen

define the corresponding C prototype as follows:

#if __GNUC__ > 7
typedef size_t fortran_charlen_t;
#else
typedef int fortran_charlen_t;
#endif

void fstrlen_ (char*, int*, fortran_charlen_t);

In order to avoid such compiler-specific details, for new code it is
instead recommended to use the ISO_C_BINDING feature.

Note with C binding, CHARACTER(len=1) result variables are returned
according to the platform ABI and no hidden length argument is used
for dummy arguments; with VALUE, those variables are passed by value.
</quote>

Bill Dunlap
TIBCO Software
wdunlap tibco.com

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Jul 6, 2020 at 3:13 PM Pierre Lafaye de Micheaux

        
<lafaye at unsw.edu.au> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Pierre Lafaye de Micheaux
    

    

      
      #
    

  


  

      
Hello Bill,

Thank you for your insight.

First, my impression, is that the problem comes from how I declare the type of the function itself (and not its parameters), since the first (and only warning they seen on the CRAN) message is:

<quote>
myzhpevx.cpp:13:16: warning: type of ?zhpevx_? does not match original declaration [-Wlto-type-mismatch]
           void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
</quote>

What I did is the following:

<quote>
void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
      const int *n, Rcomplex *ap, const double *vl,
      const double *vu, const int *il, const int *iu,
      const double *abstol, int *m, double *w,
      Rcomplex *z, const int *ldz, Rcomplex *work, double *rwork,
      int *iwork, int *ifail, int *info,
      FC_LEN_T jobz_len,  FC_LEN_T range_len,  FC_LEN_T uplo_len);

 char cjobz[2];
 strncpy(cjobz, jobz[0], 1);
 cjobz[1] = '\0';
 char crange[2];
 strncpy(crange, range[0], 1);
 crange[1] = '\0';
 char cuplo[2];
 strncpy(cuplo, uplo[0], 1);
 cuplo[1] = '\0';

 F77_CALL(zhpevx)(cjobz, crange, cuplo, &n[0], ap, &vl[0], &vu[0], &il[0], &iu[0], &abstol[0], &m[0],
  w, z, &ldz[0], work, rwork, iwork, ifail, &info[0], strlen(cjobz), strlen(crange), strlen(cuplo));
</quote>

Do you see anything wrong with the above?

Thank you

Best
Pierre

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
With gcc 8.3.0, gfortran 8.3.0, and ld 2.33.1 from the mingw64 part of
rtools40 on Windows, if I misdefine the typedef FC_LEN_T and use the
-flto flag I get the sort of error messages that you report.

c:\tmp\fortran>cat main.c
#include <string.h>
#include <stdio.h>

#ifdef USE_INT
typedef int FC_LEN_T;
#endif
#ifdef USE_LONG
typedef long int FC_LEN_T;
#endif
#ifdef USE_LONG_LONG
typedef long long int FC_LEN_T;
#endif

extern void sub_(char* word, double *ret, FC_LEN_T word_len);

int main(int argc, char* argv[])
{
    if (argc == 2) {
        double ret = 3. ;
        FC_LEN_T word_len = strlen(argv[1]);
        sub_(argv[1], &ret, word_len);
        printf("sizeof(FC_LEN_T)=%d, ret=%g\n", (int)(sizeof(FC_LEN_T)), ret);
        return 0;
    } else {
        return -1;
    }
}

c:\tmp\fortran>gcc  -flto -DUSE_INT main.c sub.f -lgfortran
main.c:14:13: warning: type of 'sub_' does not match original
declaration [-Wlto-type-mismatch]
 extern void sub_(char* word, double *ret, FC_LEN_T word_len);
             ^
sub.f:1:1: note: type mismatch in parameter 3
       subroutine sub(word, ret)
 ^
sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
sub.f:1:1: note: 'sub' was previously declared here
sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used

c:\tmp\fortran>gcc  -flto -DUSE_LONG main.c sub.f -lgfortran
main.c:14:13: warning: type of 'sub_' does not match original
declaration [-Wlto-type-mismatch]
 extern void sub_(char* word, double *ret, FC_LEN_T word_len);
             ^
sub.f:1:1: note: type mismatch in parameter 3
       subroutine sub(word, ret)
 ^
sub.f:1:1: note: type 'long long int' should match type 'FC_LEN_T'
sub.f:1:1: note: 'sub' was previously declared here
sub.f:1:1: note: code may be misoptimized unless -fno-strict-aliasing is used

c:\tmp\fortran>gcc  -flto -DUSE_LONG_LONG main.c sub.f -lgfortran
<no warnings or notes>

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Mon, Jul 6, 2020 at 4:39 PM Pierre Lafaye de Micheaux

        
<lafaye at unsw.edu.au> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Pierre Lafaye de Micheaux
    

    

      
      #
    

  


  

      
My file myzhpevx.cpp starts with:

<quote>
#define USE_FC_LEN_T
#include <R.h>
#include "Rmath.h"

#ifdef FC_LEN_T
extern "C" {

  void zhpevxC(char **jobz, char **range, char **uplo, int *n, Rcomplex *ap,
     double *vl, double *vu, int *il, int *iu, double *abstol, int *m,
     double *w, Rcomplex *z, int *ldz, Rcomplex *work, double *rwork,
     int *iwork, int *ifail, int *info) {

          void F77_NAME(zhpevx)(char *jobz, char *range, char *uplo,
      const int *n, Rcomplex *ap, const double *vl,
      const double *vu, const int *il, const int *iu,
      const double *abstol, int *m, double *w,
      Rcomplex *z, const int *ldz, Rcomplex *work, double *rwork,
      int *iwork, int *ifail, int *info,
      FC_LEN_T jobz_len,  FC_LEN_T range_len,  FC_LEN_T uplo_len);
</quote>

So if I understand correctly what you are saying, you suggest that FC_LEN_T was not correctly defined by the CRAN team?

Should I just write something like (adding the middle instruction below to my existing code above)?:

<quote>
#ifdef FC_LEN_T
typedef long long int FC_LEN_T;
extern "C" {
</quote>

Thank you
Pierre

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Tomas Kalibera
    

    

      
      #
    

  


  

      
My recommendation would be to try to minimize the example (package) as 
much as possible so that it still has the problem, and then try to 
investigate why exactly/where is the type mismatch. This is what helped 
me debug similar issues - sometimes it was hard to tell from the Fortran 
warnings where exactly the mismatched declarations were and why they 
were mismatched.

This process of minimization can already reveal the true source of the 
problem, and if not, others may try to debug for you using the minimal 
example. A useful tool is the Fortran option -fc-prototypes-external 
(see WRE for more details) and I've also used dumps of the compiler tree 
before (-fdump-tree-all, more in GCC documentation).

Best
Tomas

        
On 7/7/20 5:00 AM, Pierre Lafaye de Micheaux wrote:

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
On Tue, 7 Jul 2020 03:00:23 +0000

        
Pierre Lafaye de Micheaux <lafaye at unsw.edu.au> wrote:

        

            

      
      
      
    

        
No, I don't think that would help.

What _might_ help is adapting the incantation from [*] to redefine
FC_LEN_T to int on older GCC:

#if defined(__GNUC__) && __GNUC__ < 7
 /* Rconfig.h #define doesn't match the actual type
  * of hidden length argument in old gfortran */
 #define FC_LEN_T int
#else
 /* Otherwise we use the #define from Rconfig.h */
 #define USE_FC_LEN_T
#endif
/* Your code starts here */
#include <R.h>
/* ... */

Another option that _should_ help is rewriting zhpevxC in Fortran
2003 using its bind(c) feature. The C interoperability would ensure that
the resulting function is callable from C, while the fact that it's
written in Fortran should make it safe to call other Fortran functions:

subroutine zhpevxC(jobz, range, uplo, n, ap, vl, vu, il, iu, &
                   abstol, m, w, z, ldz, work, rwork, iwork, &
                   ifail, info) bind(c, name='zhpevxC')
 use, intrinsic :: iso_c_binding, only: c_char, c_int, c_double, &
                                        c_double_complex

 character(kind = c_char) :: jobz, range, uplo
 integer(kind = c_int) :: il, info, iu, ldz, m, n
 real(kind = c_double) :: abstol, vl, vu
 integer(kind = c_int) :: ifail( * ), iwork( * )
 real(kind = c_double) :: rwork( * ), w( * )
 complex(kind = c_double_complex) :: ap( * ), work( * ), z( ldz, * )

 call zhpevx(JOBZ, RANGE, UPLO, N, AP, VL, VU, IL, IU, &
             abstol, m, w, z, ldz, work, rwork, iwork, &
             ifail, info)

end subroutine

A subroutine defined like this can be represented by the following C++
prototype: 

extern "C" void zhpevx(
	char * JOBZ, char * RANGE, char * UPLO, int * N,
	std::complex<double> * AP, double * VL, double * VU, int * IL,
	int * IU, double * abstol, int * m, double * w,
	std::complex<double> * z, int * ldz, std::complex<double> *
	work, double * rwork, int * iwork, int * ifail, int * info
);

This is the approach described in WRE 6.6.1 Fortran character strings
near the code block with the definition of subroutine c_dgemm.