Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

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

vvnurmi
Beginner
316 Views

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

0 Kudos
5 Replies
jimdempseyatthecove
Honored Contributor III
316 Views
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
0 Kudos
Steven_L_Intel1
Employee
316 Views
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.
0 Kudos
Jeffrey_C_
Beginner
316 Views

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

0 Kudos
Steven_L_Intel1
Employee
316 Views

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.

0 Kudos
Steven_L_Intel1
Employee
316 Views

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.

0 Kudos
Reply