Different interfaces cause problem in 4.5, but not 4.4

[Paul van Delst]

Hi Tobias,

Thanks very much for the clarification. I did look through the f95 standard but couldn't find the relevant section (how
do you remember where to look? :o)

Again, vielen Dank.

cheers,

paulv


Tobias Burnus wrote:
>  Dear Paul,
> 
> Paul van Delst wrote:
>> Please consider the following code:
>>
>>    subroutine esmf_gridcompsetservices (subroutinename)
>>      implicit none
>>      interface
>>        subroutine subroutinename (rc)
>>          integer :: rc
>> [...]
>>    subroutine nems_register(rc)
>>      integer,intent(out) :: rc
>> [...]
>>    call esmf_gridcompsetservices(nems_register)
> 
>> When compiled with gfortran 4.5 we get the following:
>>
>>   call esmf_gridcompsetservices(nems_register)
>>                                 1
>> Error: Interface mismatch in dummy procedure 'subroutinename' at (1):
>> INTENT mismatch in argument 'rc'
>>
>> My initial reaction when I was shown this code, and told gfortran 4.5
>> wouldn't compile it, was that the interfaces were different so it
>> shouldn't compile.
>>
>> But then when I tried gfortran 4.4 it worked. And the test code
>> compiles and runs as expected with g95, pgf95, ifort (on linux) and
>> xlf95 on AIX.
> 
> If you look for another compiler which does not like the code, try NAG:
> 
> Error: line 26: Dummy proc SUBROUTINENAME arg 1 has different INTENT
> from actual proc NEMS_REGISTER arg
> Error: line 26: Incompatible procedure argument for SUBROUTINENAME (no.
> 1) of ESMF_GRIDCOMPSETSERVICES
> 
> As both NAG and gfortran 4.5/4.6 try to tell you: Passing a procedure
> with having an INTENT specifies as actual argument to a dummy procedure
> with arguments which do not have an INTENT is invalid. Or to quote the
> standard (from Fortran 2008, which meanwhile has been published by ISO):
> 
> "12.5.2.9 Actual arguments associated with dummy procedure entities"
> [...]
> "If the interface of a dummy procedure is explicit, its characteristics
> as a procedure (12.3.1) shall be the same as those of its effective
> argument, except that a pure effective argument may be associated with a
> dummy argument that is not pure and an elemental intrinsic actual
> procedure may be associated with a dummy procedure (which cannot be
> elemental)."
> 
> And jumping to 12.3.1 one finds:
> 
> "The characteristics of a procedure are [...] the characteristics of its
> dummy arguments,"
> [...]
> "The characteristics of a dummy data object are [...] its intent
> (5.3.10, 5.4.9),"
> 
> As those are no constraints (C<number>), the compiler does not have to
> diagnose it, but - as Richard Maine usually puts it - it is a matter of
> quality of implementation.
> 
> Tobias,
> who has already found a bug in a program due to this checking where a
> procedure with an INTENT(OUT) dummy was passed to a dummy procedure with
> an INTENT(IN) dummy argument.
> 
> PS: Do not underestimate the importance of INTENT for the program
> correctness. Especially if one uses INTENT(IN), gfortran does all kind
> of optimizations which leads to wrong code if the argument is modified.
> I think there are not yet any optimizations done in the caller for
> INTENT(OUT), but that might come.

-- 
Paul van Delst