topic Has this issue since been in Intel® Fortran Compiler

Error #6633 when type declared in module and used in module procedure and global procedure

vvnurmi — Mon, 26 Sep 2011 12:36:21 GMT

Hello!

The following program gives "error #6633: The type of the actual argument differs from the type of the dummy argument. [VAL]" (see comment in the code) when I compile it like this:

ifort /gen-interfaces /compile-only moduletypetest.f90
ifort /warn:all moduletypetest.f90

I'm usingIntel Visual Fortran Compiler XE for applications running on IA-32, Version 12.0.5.221 Build 20110719.

I browsed through some other forum posts about error #6633 and in many cases the problem was that the derived type was declared separately in several places. The suggested solution in those cases was to declare the derived type in a module and use the module. Superficially it would seem that I'm not doing against that advice in this program. But does something similar still happen, i.e. is the derived type somehow declared separately for procedures foo and bar?

module mymod
type mytype
integer :: x
end type mytype
contains
subroutine foo()
type(mytype) :: val
call bar( val ) !error #6633: The type of the actual argument differs from the type of the dummy argument. [VAL]
end subroutine foo
end module mymod

subroutine bar( val )
use mymod
type(mytype) :: val
write(*,*) val
end subroutine bar

program moduletypetest
use mymod
call foo()
end program moduletypetest

Thanks for the help,

-Ville

Error #6633 when type declared in module and used in module pro

jimdempseyatthecove — Mon, 26 Sep 2011 14:57:37 GMT

Make an interface block for bar

module mymod
type mytype
integer :: x
end type mytype
interface
subroutine bar( val )
type(mytype) :: val
end subroutine bar
end interface
contains
subroutine foo()
...

Jim Dempsey

Error #6633 when type declared in module and used in module pro

Steven_L_Intel1 — Mon, 26 Sep 2011 14:58:11 GMT

Your code is correct, as far as I know. I don't know why /warn:interface is giving the error. I will ask the developers about this It is more puzzling to me that the call to bar gets the diagnostic only if a separate compile generating the __genmod.mod file has been done first. It's supposed to recheck things if it sees a reference to something declared later in the source. Issue ID is DPD200174083.

Has this issue since been

Jeffrey_C_ — Mon, 09 Jun 2014 17:49:58 GMT

Has this issue since been resolved? My error seems to be nearly identical.

No, it's still open. Can you

Steven_L_Intel1 — Mon, 09 Jun 2014 18:10:38 GMT

No, it's still open. Can you provide a test case that shows your problem? Sometimes there are multiple issues that result in the same error.

The developers informed me

Steven_L_Intel1 — Tue, 10 Jun 2014 15:58:04 GMT

The developers informed me that the error message is fixed for the 15.0 release coming out later this year, in the situation from the original post. One could still have a problem if you had a module referencing an external procedure declared later in the same source file where the interface to the procedure was changed. In this case, the compiler would see any old generated interface information. This is not a common programming style and we don't have plans to change the behavior.