Re: Assumed-shape arrays and dummy procedures

"bill" <w.mclean@xxxxxxxxxxx> wrote in message
news:e450c51d-fbaf-4c18-afc6-16665227e0f8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The characteristics of dummy argument 1 of the associated actual
procedure differ from the characteristics of dummy argument 1 of the
dummy procedure. (12.2) [BAR]
call wrapcall(x, bar)
--------------^
compilation aborted for runfoo.f90 (code 1)

Yeah, ifort has done this since the cvf or even dvf days. It behaves
as though it were building data structures corresponding to dummy
procedures and passing them around via the *.mod files. You get
spoiled by this extra degree of interface checking if dvf/cvf/ifort
is all you ever used, and when you try other compilers generally
you find that they can't distinguish between a function and a
subroutine dummy argument, much less check the whole signature of
the procedure. The reason for this lies in the possibility for a
dummy argument to simply be declared EXTERNAL and impicitly typed
so there is no way for the caller to check its interface. And you
can't require explicit interfaces for everything: what if a
RECURSIVE procedure could be passes itself as an actual argument?
Well, maybe there is no possible useful code where that happens,
but there is no linguistic prohibition either, so you have to take
into account dummies being declared EXTERNAL and implicitly typed,
hence being total wild cards.

There is a good reason for Intel and predecessors to check
procedure arguments possibly to the extent of building data
structures containing their interfaces: mismatched procedure
interfaces are ugly to debug because everything is OK in both the
caller and the callee, it's just the interaction between the two
that's a bug. There is good reason for other vendors not to do
so, however: it's always possible to subvert any procedure
interface checking mechanism, whether intentionally or through
code that is just complicated. Also any feature like this can
be tripped up to the extent of causing errors or ICE. Did
anyone suspect an example was coming?

C:\gfortran\clf\ambinterf>type ambinterf.f90
! File: ambinterf.f90
! Public domain 2008 James Van Buskirk
module interfs
implicit none
contains
subroutine callthru(qsub, option)
implicit logical(q)
integer, intent(in) :: option
external qsub

if(option == 1) then
write(*,'(a)') 'Calling subroutine A'
call A(qsub, 2)
else if(option == 2) then
write(*,'(a)') 'Calling subroutine B'
call B(qsub, 2)
else if(option == 3) then
write(*,'(a)') 'Calling subroutine C'
call C(qsub, 2)
end if
end subroutine callthru

subroutine A(sub, n)
integer, intent(in) :: n
interface
subroutine sub(x)
implicit none
real, intent(in) :: x(:)
end subroutine sub
end interface
real x(n)
integer i

x = [(i,i=1,n)]
call sub(x)
end subroutine A

subroutine subA(x)
real, intent(in) :: x(:)

write(*,*) 'In subA, x = ', x
end subroutine subA

subroutine B(sub, n)
integer, intent(in) :: n
interface
function sub(x)
implicit none
integer, intent(in) :: x
logical sub(x)
end function sub
end interface

write(*,*) 'Result of subB = ', sub(n)
end subroutine B

function subB(x)
integer, intent(in) :: x
logical subB(x)
integer i

subB = [(modulo(i,2) == 0,i=1,x)]
end function subB

subroutine C(sub, n)
integer, intent(in) :: n
interface
function sub(n)
implicit none
integer, intent(in) :: n
integer sub
end function sub
end interface

if(n /= 2) then
write(*,*) 'In subroutine C, result of subC = ', sub(n)
else
write(*,*) 'Nothing to do in subroutine C'
end if
end subroutine C

subroutine subC(n)
integer, intent(in) :: n

write(*,*) 'Shouldn''t have reached this statement'
end subroutine subC
end module interfs

program ambiguous
use interfs
implicit none
integer n

n = 1
call callthru(subA, n)
n = 2
call callthru(subB, n)
n = 3
call callthru(subC, n)
end program ambiguous
! End of file: ambinterf.f90

C:\gfortran\clf\ambinterf>c:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
ambinte
rf.f90 -oambinterf
ambinterf.f90:16.19:

call B(qsub, 2)
1
Error: Type/rank mismatch in argument 'sub' at (1)
ambinterf.f90:19.19:

call C(qsub, 2)
1
Error: Type/rank mismatch in argument 'sub' at (1)
ambinterf.f90:90.14:

use interfs
1
Fatal Error: Can't open module file 'interfs.mod' for reading at (1): No
such fi
le or directory
x86_64-pc-mingw32-gfortran: Internal error: Aborted (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

C:\gfortran\clf\ambinterf>ifort ambinterf.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

ambinterf.f90(97) : Error: The shape matching rules of actual arguments and
dumm
y arguments have been violated. [SUBB]
call callthru(subB, n)
-----------------^
compilation aborted for ambinterf.f90 (code 1)

Jeez, I thought gfortran would pass this and ifort reject it but
they are both abusing me here! Is there something really wrong
with the above code?

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.

Relevant Pages