Error 6633: Calling a function from a module, passing a module-defined type

[bealeja]

Hello,

I am wrestling with the static analysis capabilities of Intel Fortran, trying to find whatever is causing my application to crash intermittently.

I am experiencing the following:

Compiling with Intel(R) Visual Fortran Compiler XE 14.0.1.139 [Intel(R) 64]...

metmin_module.f90(1257): error #6633: The type of the actual argument differs from the type of the dummy argument.   [METEO]

Here are excerpts from the program which are hopefully sufficient to understand what is going on.  

I'd really appreciate any suggestions to get past this, since this is probably not even related to the real issue I'm having.

Thanks, Jim

----------------------------------------------------------------------------------------

MODULE METMIN_MODULE

TYPE METMIN
   INTEGER    :: IVEMET
   INTEGER    :: NSOND
   INTEGER    :: NMSUR
   INTEGER,DIMENSION(:), POINTER :: NNIV => NULL()
   ! [...]
END TYPE METMIN

CONTAINS

INTEGER FUNCTION GETNEW_METMIN( IMET,ISENS,IECHAN,ITEUSE, &
         DICTIO,  &
         CODINV,NTIMEC, &
         NSTAMA,NRSMAX,NIVMAX, &
         JOUR , &
         METEO, &
         IOUT,IMPRS,IFICBA)  

! [...]

TYPE(METMIN), INTENT(INOUT) :: METEO

! [...]

  CALL GETMET(  &
     ILEC,ISENS,IECHAN,ITEUSE, &
     DICTIO,  &
     CODINV,NTIMEC, &
     NSTAMA,NRSMAX,NIVMAX, &
     JOUR , &
     METEO, &                               ! <<--------------- LINE 1257 is here (see error msg)
     IOUT,IMPRS,GETNEW_METMIN)

END FUNCTION GETNEW_METMIN

END MODULE
---------------

getmet(...) resides in a different file, getmet.f90, wherein we find

---------------
SUBROUTINE GETMET(  &
         ILEC,ISENS,IECHAN,ITEUSE, &
         DICTIO,  &
         CODINV,NTIMEC, &
         NSTAMA,NRSMAX,NIVMAX, &
         JOUR , &
         METEO, &
         IOUT,IMPRS,IERREU)

USE METMIN_MODULE

TYPE(METMIN), INTENT(INOUT) :: METEO

END SUBROUTINE

[bealeja]

Is the information I provided sufficiently clear? Does anyone have any input on this question at all?? :)

[Roland_W_Intel1]

I can't see anything wrong with this.  I tried to create a test case with the code you provided and could not reproduce the error.  If you can provide a reproducer, submit an issue through Intel Premier Support and we will investigate.

[bealeja]

Hi Roland!

Thanks for the reply.  I will try to create a test case which reproduces the issue.  As I mentioned in my original post, this issue is probably not related to the serious issue I am facing - intermittent crashing in innocuous places.  I wasn't having any such problems with 32bit but with 64bit, I've started having all kinds of strange problems.  I'm hoping static analysis can help because running debug and/or adding print statements make the problem go away.  :(

Thanks!

Jim

[bealeja]

I was able to reproduce this issue easily enough.  I'll attach my files.  One thing that might not have been clear from my original post is that the error only occurs when compiling with static analysis turned on.  The complete command line is,

/nologo /debug:full /Od /Qdiag-enable:sc2 /Qdiag-enable:sc-concise /Qdiag-enable:sc-include /Qdiag-enable:sc-single-file /warn:interfaces /module:"Debug\\" /object:"Debug\\" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c

The error is the same as before,

error #6633: The type of the actual argument differs from the type of the dummy argument.   [METEO]

And hopefully I'll be able to attach the files. :)

Thanks for taking a look at this!

Jim

[Steven_L_Intel1]

I see the issue. The reason you think Static Analysis is involved is that you don't see the error unless getmet.f90 is compiled before metmin_module.f90. But what really happens is that you do a build, make a change, any change, to metmin_module.f90, and do a build again. Now when the module is compiled it sees the generated interface information from the earlier compile of getmet.f90 and that triggers the error.

The compiler shouldn't be complaining about this - my guess is that it is confused when the type comes from the module currently being compiled.  I can think of several workarounds, one of which would be to move subroutine getmet into the module as a contained procedure or into its own module so that it has an explicit interface.

I will report this to the developers. Issue ID is DPD200250382.

[Steven_L_Intel1]

We have fixed this for a release later this year. Thanks for bringing it to our attention.