topic I understand why it might do in Intel® Fortran Compiler

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

Prof__Beck — Wed, 11 Apr 2012 19:58:49 GMT

Ever since I installed Intel Visual Fortran V. 11.1.048, I cannot compile my formally working code in DEBUG mode.

In several instances where I am passing an user-defined data(type) variable as a parameter to a subroutine, I get the following error message: "error #6633: The type of the actual argument differs from the type of the dummy argument." However, the user-defined data variable is explicitly declared in both the calling and the called subroutines. My feeling is that this is a BUG of the Intel Fortran compiler, because:
1. WhenI compile the code in DEBUG Win 32 I get many of the same error messages;
2. when I compile the code in DEBUG x64 I get less but the same error message;
3. When I compile the code in RELEASE mode, either for Win32 or x64, the code compiles, builds and works perfectly...!

Follows an example of the source code:

calling routine:
SUBROUTINE READ_CONT_RANDOM_VARIABLE_DATA (INPUT, CRV)
IMPLICIT NONE
INTEGER INPUT !INPUT FILE NUMBER
TYPE(CONT_RANDOM_VARIABLE),INTENT(INOUT) :: CRV
...
CALL CRV_PARAMETER_EVAL(CRV); !!!!!! THIS IS WHERE I GET THE ERROR MESSAGE !!!!!!...
...
END SUBROUTINE READ_CONT_RANDOM_VARIABLE_DATA

called subroutine:
SUBROUTINE CRV_PARAMETER_EVAL(CRV)
IMPLICIT NONE
TYPE(CONT_RANDOM_VARIABLE),INTENT(INOUT) :: CRV
....
END SUBROUTINE CRV_PARAMETER_EVAL

error #6633: The type of the actual argument differs from the t

Steven_L_Intel1 — Wed, 11 Apr 2012 20:26:26 GMT

Where is the definition of type CONT_RANDOM_VARIABLE? How is that definition provided to the caller and the called procedure? My guess is that it comes from an INCLUDE file and these subroutines are separate (not in a module or contained. A Debug configuration enables "generated interface checking", which looks for consistency across calls to external procedures - a Release configuration does not.

The evidence so far suggests that the compiler is correct.

error #6633: The type of the actual argument differs from the t

Johannes_Rieke — Thu, 12 Apr 2012 09:37:59 GMT

Could that be the same problem as reported in this old thread?

http://software.intel.com/en-us/forums/showthread.php?t=86588&o=a&s=lr

I had also some problems with interface checking but this was concerning character variables passed with wild-cards in the dummy entries used in some old libraries formerly compiled with CVF and now ported to ifort. As suggested somewhere in this forum, I turned off the checking. Running the program never caused an error so far.

Greetings,
Johannes

error #6633: The type of the actual argument differs from the t

Steven_L_Intel1 — Fri, 13 Apr 2012 00:47:09 GMT

Without seeing the whole code, I can't tell.

error #6633: The type of the actual argument differs from the t

Prof__Beck — Tue, 17 Apr 2012 18:26:05 GMT

Dear Steve, thanks for your reply...

Your guess was wrong, the definition of CONT_RANDOM_VARIABLE is in the same MODULE as both calling and caller procedures... There are no INCLUDE comands.

Any other guess?

Andre

error #6633: The type of the actual argument differs from the t

Steven_L_Intel1 — Tue, 17 Apr 2012 19:04:35 GMT

At this point, I will wait for the complete example from you.

I also get this error and

antony — Tue, 18 Sep 2012 14:25:18 GMT

I also get this error and believe it is a bug (Composer 2013 and for a while). It depends on context - a clean debug build works, a partial one doesn't. E.g. try the attached. If I do Clean Solution, then Build, all is OK. If I then run Build *again* I get errors. If I do Clean Solution, then Build, all is OK. If I then use Compile (e.g. Ctrl+F7 on cmbmain), I get some different errors. If I do Clean Solution, then Build, all is OK. If I then use Compile (e.g. Ctrl+F7 on modules), I get some different [clearly wrong] errors (some of the errors are sort-of true, but it is correct code and anyway if there should be a warning you should get it on the first build too!) Thanks, Antony

The reason the initial build

Steven_L_Intel1 — Tue, 18 Sep 2012 14:41:47 GMT

The reason the initial build works is that subroutine DVERK (subroutines.f90) hasn't yet been compiled when the call to DVERK in recfast.f90 is compiled, so it doesn't know the interface. When you do the second build, the generated interface for DVERK is available and the compiler sees that there is a mismatch. The code is NOT correct - in Recombination_init, RECOMB is TYPE(RecombinationParams), but the corresponding dummy argument EV in DVERK is REAL. I didn't look at the others. If you want to allow the mismatch, add: !DEC$ ATTRIBUTES NO_ARG_CHECK :: EV in DVERK.

I understand why it might do

antony — Tue, 18 Sep 2012 15:40:45 GMT

I understand why it might do it, but it is inconsistent behaviour isn't it - to only sometimes give the error (and not at all on a clean build, which is how I would most likely try to run a check like this)? I agree the error (as a warning, not an error) would be valid in the first case: the code is only correct in that using wrong types is the only way to mimic class(*) parameters in standard F90 (types for non-module subroutines are not checked - the code compiles and runs fine in all compilers - the parameter is just a pointer). Thanks for hint about !DEC$ ATTRIBUTES NO_ARG_CHECK :: EV. But when I compile with this I get Error 1 error #7673: The DEC$ ATTRIBUTES NO_ARG_CHECK directive shall appear only in an interface block or module procedure. [NO_ARG_CHECK] C:\Work\Devel\camb\source\subroutines.f90 376 The third error I mention is however (I think) clearly wrong, in that everything has the right type. I think it originates because the type is defined in the file being recompiled, but used by a subroutine in the calling file (which is not recompiled), so it erroneously things the newly-compiled type is different from the type used in the calling file. The subroutine circularity appears to be valid fortran. Antony

On first look, I am inclined

Steven_L_Intel1 — Tue, 18 Sep 2012 19:18:26 GMT

On first look, I am inclined to agree that the last set of errors is not appropriate. I'll look at that closer tomorrow.

Thank you for your replies:

alexandre_h_ — Mon, 06 Jan 2014 15:43:02 GMT

Thank you for your replies: Here is some example

     REAL T, P,...
...
     CALL DDTCI (1, T, RPDS, LGLSA, LGFR, YF, 
     &              XOM, XLAM, ITYP2P,
     :              ZF, X, Y, Z, XW, YW, ZW, XY, XZ, AD, CDZ, S, LGSMTH,
     .              THETAW, ISIDES,
     :              LPOIN2, WORK1, WORK2, WORK3, WORK4, WORK5, 
     :              LGABRT)

 
     SUBROUTINE DDTCI (NT, T, P, LGLSA, LGFR, YF, XOM, XLAM, ITYP2P,
     .            ZF, X, Y, Z, XW, YW, ZW, XY, XZ, AD, CD, S, LGSMTH,
     :            THTAWD,
     .            ISIDES, NMAX, WORK1, WORK2, WORK3, WORK4, WORK5, 
     .            LGABRT)

      REAL T, P,...
      DIMENSION T(*), P(*),...

this is the typical case where the function expects arrays, and the call is done with values and dimension 1.
It is produce by /warn:interfaces, this is part of diagnostics, turning it off, code compiles and runs correctly.

1/ indeed changes could be done to T, RPDS, etc. in the calling code, and turn them into array and back into values, now, I would rather not change this legacy code that is working and add more complexity to it.

2/ usage of !DEC$ ATTRIBUTES NO_ARG_CHECK :: dummy-arg-name would disable the checks for all calls to DDTCI, no? whereas I just want to turn off the checks for this call

3/ My issue is not so much how to fix the code, but how I can keep a high level of check on my solution (i.e. all /warn on) while disabling specific error/warning on some specific files where the code is too hard to fix without major rewrite

Thank you!

Show me an example call. If

Steven_L_Intel1 — Mon, 06 Jan 2014 18:33:45 GMT

Show me an example call. If you are passing input values, you can enclose the scalar argument in [] and that turns it into an array. This won't work if the subroutine writes to the argument.