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

This error is given by the Intel Fortran compiler when it can see that the data type of an actual argument in a call to a procedure is different from that of the corresponding dummy argument in the called procedure.  Consider this simple example:

integer i
call sub (i)
subroutine sub (x)
real x
The Fortran standard requires that actual and dummy arguments match in type, kind and rank - often referred to as "TKR".  Type can be an intrinsic type, such as INTEGER or CHARACTER, or can be a derived type. Kind is which kind of intrinsic type.  For example, in INTEGER(4), the kind is 4. (Note that if the *n notation is used, the *n value may or may not be the same as the kind value.)  Rank is the number of dimensions (scalars have zero rank.)

Normally, the compiler can "see" the types of the dummy arguments only if an explicit interface is visible.  This can be provided if the called procedure is in a module, if it is a CONTAINed procedure, or if an INTERFACE block for it is visible.  If the called procedure is an external procedure, not in a module or contained, then the compiler can't see the explicit interface.

However, Intel Fortran has an optional diagnostic feature, Generated Interface Checking, which creates explicit interfaces when an external procedure is compiled, and then when a call is made to a procedure for which no explicit interface is visible, the compiler uses the generated interface for error checking. (The generated interface does satisfy the Fortran language's requirements for when an explicit interface must be visible.)  Generated Interface Checking is on by default in a Debug configuration in a Visual Studio project on Windows.  From the command line, it can be enabled using the /warn:interface (Windows) or -warn interface (Linux and Mac OS) options.

In most cases, a type mismatch can cause incorrect results and such errors should be fixed in the program source.  Some applications were written for compilers that did not check external procedures and for which the type mismatch is harmless.  If you know that yours is such a case, you can add a directive in the called procedure to tell the compiler to ignore the type.  This is

!DEC$ ATTRIBUTES NO_ARG_CHECK :: dummy_arg_name

You should be aware that passing a non-REAL value to a REAL dummy argument can cause run-time errors or, in some cases, have the value change.  If you are deliberately mismatching types, you should avoid the use of REAL, DOUBLE PRECISION or COMPLEX for the dummy argument type.
For more complete information about compiler optimizations, see our Optimization Notice.