gfortran and "Type/rank mismatch"

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

> 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

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

JKB <knatschke@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

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

Le 23-10-2006, à propos de
Re: gfortran and "Type/rank mismatch",
Richard Maine écrivait dans comp.lang.fortran :
> JKB <knatschke@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.

I don't understand. I only use this subroutine to call a C function
from a Fortran program. GSL_DF_RESULT is only defined in this
subroutine. I don't see the differences between the argument and the
dummy argument.

Regards,

JKB

Le 23-10-2006, à propos de
Re: gfortran and "Type/rank mismatch",
Craig Powers écrivait dans comp.lang.fortran :
> 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).

OK. It compiles. I don't know this statement and I don't have this
one in the book I use...

> Add SEQUENCE immediately after the TYPE line on both declarations to fix
> this, e.g.

Thanks,

JKB

JKB <knatschke@koenigsberg.fr> wrote:

> Le 23-10-2006, à propos de
> Re: gfortran and "Type/rank mismatch",
> Richard Maine écrivait dans comp.lang.fortran :

> > The error is that
> > the code has multiple definitions of the type gsl_sf_result.

> I don't understand. I only use this subroutine to call a C function
> from a Fortran program. GSL_DF_RESULT is only defined in this
> subroutine. I don't see the differences between the argument and the
> dummy argument.

The "in this subroutine" bit doesn't matter. There are 2 definitions.
Count them. One is in the interface body, and one is outside of it. An
interface body has its own scope. (And it has to - there are debates
about whether it should be able to inherit names from its host, but none
about whether it has to have its own scope). If you see 2 definitions of
a type, no matter where they are, and if it isn't a sequence type, then
those 2 definitions don't count as the same. As mentioned before, it
doesn't matter that you can't see the difference. It only matters that
there are 2 of them.

Oh. And if it is a C routine, then you want the sequence attribute
anyway. That attribute increases the odds that the type will be laid out
in memory the same way as the C code expects. It doesn't guarantee such
a layout, but it improves the odds. In f2003, you can declare the type
to be BIND(C), which actually guarantees it. For now, use sequence.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Le 23-10-2006, à propos de
Re: gfortran and "Type/rank mismatch",
Richard Maine écrivait dans comp.lang.fortran :
> JKB <knatschke@koenigsberg.fr> wrote:
>
>> Le 23-10-2006, à propos de
>> Re: gfortran and "Type/rank mismatch",
>> Richard Maine écrivait dans comp.lang.fortran :
>
>> > The error is that
>> > the code has multiple definitions of the type gsl_sf_result.
>
>> I don't understand. I only use this subroutine to call a C function
>> from a Fortran program. GSL_DF_RESULT is only defined in this
>> subroutine. I don't see the differences between the argument and the
>> dummy argument.
>
> The "in this subroutine" bit doesn't matter. There are 2 definitions.
> Count them. One is in the interface body, and one is outside of it. An
> interface body has its own scope. (And it has to - there are debates
> about whether it should be able to inherit names from its host, but none
> about whether it has to have its own scope). If you see 2 definitions of
> a type, no matter where they are, and if it isn't a sequence type, then
> those 2 definitions don't count as the same. As mentioned before, it
> doesn't matter that you can't see the difference. It only matters that
> there are 2 of them.
>
> Oh. And if it is a C routine, then you want the sequence attribute
> anyway. That attribute increases the odds that the type will be laid out
> in memory the same way as the C code expects. It doesn't guarantee such
> a layout, but it improves the odds. In f2003, you can declare the type
> to be BIND(C), which actually guarantees it. For now, use sequence.

Thanks for your explanation,

JKB

In article <slrnejq2pr.3kl.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:
> Le 23-10-2006, à propos de
> Re: gfortran and "Type/rank mismatch",
> Richard Maine écrivait dans comp.lang.fortran :
>> JKB <knatschke@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.
>
> I don't understand. I only use this subroutine to call a C function
> from a Fortran program. GSL_DF_RESULT is only defined in this
> subroutine. I don't see the differences between the argument and the
> dummy argument.
>
> Regards,
>
> JKB

What Richard and Craig have told you is that two declarations
are not the same type. Even though "Declaration #1" and
"Declaration #2" below look the same a compiler is free
to write VALEUR, ERREUR into memory for #1 and ERREUR, VALEUR
into memory for #2.

subroutine GAMMALN(X, RESULTAT, SIGNE, ERREUR)

! Declaration #1
type GSL_SF_RESULT
real*8 VALEUR
real*8 ERREUR
end type

interface
integer function gsl_sf_lngamma_sgn_e_wrapper(X, RESULTAT,SIGNE)
! Declaration #2
type GSL_SF_RESULT
real*8 VALEUR
real*8 ERREUR
end type
end function
end interface

end subroutine

To guarantee the order of the derived type, you should change it to

type GSL_SF_RESULT
sequence
real*8 VALEUR
real*8 ERREUR
end type

A compiler can now infer that the two types are the same.

BTW, like Richard, I think the use of a module is a good idea.

--
Steve
http://troutmask.apl.washington.edu/~kargl/