gfortran and "Type/rank mismatch"
in [Fortran]
|
From: JKB on 23 Oct 2006 13:45 Hello, I have found this code : ubroutine GAMMALN(X, RESULTAT, SIGNE, ERREUR) implicit none real*8, intent(in) :: X integer*8, intent(out), optional :: ERREUR real*8, intent(out) :: RESULTAT real*8, intent(out), optional :: SIGNE integer*8 ERREUR_GAMMA real*8 SIGNE_GAMMA type GSL_SF_RESULT real*8 VALEUR real*8 ERREUR end type type(GSL_SF_RESULT) STRUCT_RESULTAT interface integer function gsl_sf_lngamma_sgn_e_wrapper(X, RESULTAT, SIGNE) implicit none type GSL_SF_RESULT real*8 VALEUR real*8 ERREUR end type real*8, intent(in) :: X type(GSL_SF_RESULT), intent(out) :: RESULTAT real*8, intent(out) :: SIGNE end function end interface ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & SIGNE_GAMMA) RESULTAT = STRUCT_RESULTAT%VALEUR if (present(SIGNE)) then SIGNE = SIGNE_GAMMA end if if (present(ERREUR)) then ERREUR = ERREUR_GAMMA end if return end subroutine that can be compiled with gfortran 4.0. With 4.1, I obtain the following message : In file fonctions_speciales.conv.f90:71 ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & 1 Error: Type/rank mismatch in argument 'resultat' at (1) Only one question (I think that this code has to compile...). Is there a bug in gfortran 4.1 ? What is this kind of error ? Thans in advance, JKB
From: FX on 23 Oct 2006 14:05 > In file fonctions_speciales.conv.f90:71 > > ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & > 1 > Error: Type/rank mismatch in argument 'resultat' at (1) Sun compiler also gives: ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & ^ "foo.f90", Line = 35, Column = 52: ERROR: The type of the actual argument, "type(GSL_SF_RESULT)", does not match "type(GSL_SF_RESULT)", the type of the dummy argument. -- FX
From: JKB on 23 Oct 2006 14:10 Le 23-10-2006, ? propos de Re: gfortran and "Type/rank mismatch", FX ?crivait dans comp.lang.fortran : >> In file fonctions_speciales.conv.f90:71 >> >> ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & >> 1 >> Error: Type/rank mismatch in argument 'resultat' at (1) > > Sun compiler also gives: > > > ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & > ^ > "foo.f90", Line = 35, Column = 52: ERROR: The type of the actual > argument, "type(GSL_SF_RESULT)", does not match "type(GSL_SF_RESULT)", > the type of the dummy argument. I don't see the mistake... Any idea ? JKB
From: Richard Maine on 23 Oct 2006 14:21 JKB <knatschke(a)koenigsberg.fr> wrote: [code elided] > Only one question (I think that this code has to compile...). Is > there a bug in gfortran 4.1 ? What is this kind of error ? The code is incorrect. No it doesn't "have to compile". It was probably compiled on some compiler that didn't catch the error. The error is that the code has multiple definitions of the type gsl_sf_result. Each of these definitions counts as a different type, no matter how simillar the definitions look . Even if they are textually identical, they still count as different types. Thus the types of your actual and dummy arguments don't match. If you want to pass arguments of derived type, you must do one of two things. 1. Use only a single type definition. Pretty much the only way to do this in most cases is to put the type definition in a module and USE the module in the calling and called procedures. An internal procedure can do it with host association, but that's pretty limitting. The above approach is what I generally recommend. Many f90 features work much more cleanly with modules. This is one of them. I see some other signs of the code avoiding modules, though. In particular, if it used module procedures, then the interface bodies would not be needed. 2. If you don't want to put the type definition in a module, then you must declare it to be a sequence type. You do that by putting a sequence statement in each copy of the type definition. The sequence statement basically means that the type matches other types that are declared sufficiently simillarly. I'll not quote the details of the required similarity here (I'd have to look them up first to make sure I had them right), but yours are certainly plenty similar. The original code was clearly assuming that the types acted like sequence types, even though they weren't declared that way. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: Craig Powers on 23 Oct 2006 14:28
JKB wrote: > Le 23-10-2006, ? propos de > Re: gfortran and "Type/rank mismatch", > FX ?crivait dans comp.lang.fortran : >>> In file fonctions_speciales.conv.f90:71 >>> >>> ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & >>> 1 >>> Error: Type/rank mismatch in argument 'resultat' at (1) >> Sun compiler also gives: >> >> >> ERREUR_GAMMA = gsl_sf_lngamma_sgn_e_wrapper(X, STRUCT_RESULTAT, & >> ^ >> "foo.f90", Line = 35, Column = 52: ERROR: The type of the actual >> argument, "type(GSL_SF_RESULT)", does not match "type(GSL_SF_RESULT)", >> the type of the dummy argument. > > I don't see the mistake... Any idea ? The types aren't sequence types, so the one in the interface is different from the one in the parent, even though they have the same names and contents (because the lack of SEQUENCE allows the compiler to re-order the members at will, I believe). Add SEQUENCE immediately after the TYPE line on both declarations to fix this, e.g. TYPE GSL_SF_RESULT SEQUENCE ! .... END TYPE |