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.

3 comments

Top
FRANCE, ADIL's picture

Dear All,

Could you please help me to solve my problem.

The error message is :  

Error 1 error #6633: The type of the actual argument differs from the type of the dummy argument.   [WV1S] H:\UMAT\test1\anisob.for 36  Below is my code. In advance, many thanks for your help.Kind regards.

 

      program test  
      
       DIMENSION S1(6,6)
       DIMENSION WV1S(6,6)
       DIMENSION IPIV(6), WORK(6)
       INTEGER INFO
       PARAMETER(ZERO=0.D0, ONE=1.D0, TWO=2.D0, THREE=3.D0, SIX=6.D0,
     1           ENUMAX=.4999D0, NEWTON=20, TOL=1.0D-6, NTENS=6.D0)  

       EMOD1=3
       ENU1=0.3
C
C      VISCOELASTIC STIFFNESSES
C       
       E3BULK1=EMOD1/(ONE-TWO*ENU1)
       E2G1=EMOD1/(ONE+ENU1)
       ELAM1=(E3BULK1-E2G1)/THREE 
       S1=ZERO
        
       DO K1=1, 3
         DO K2=1, 3
           S1(K2,K1)=ELAM1
         END DO
         S1(K1,K1)=E2G1+ELAM1
       END DO     
       DO K1=4, 6
       S1(K1,K1)=E2G1/TWO
       END DO 
 
C      WV1S  WV2S WV3S
       WV1S=V1
       CALL DGETRF( NTENS, NTENS, WV1S, NTENS, IPIV, INFO )
       CALL DGETRI( NTENS, WV1S, NTENS, IPIV, WORK, NTENS, INFO )
       write(*,*), V1
       write(*,*)
       write(*,*),WV1S
       
      end program test
       
       INCLUDE 'lapack/double/dgetri.f'
       INCLUDE 'lapack/double/dtrti2.f'
       INCLUDE 'lapack/double/dtrtri.f'
       INCLUDE 'lapack/double/dgetf2.f'
       INCLUDE 'lapack/double/dgetrf.f'
       INCLUDE 'lapack/double/dlaswp.f'
       INCLUDE 'lapack/util/ieeeck.f'
       INCLUDE 'lapack/util/ilaenv.f'
       INCLUDE 'lapack/util/lsame.f'
       INCLUDE 'lapack/util/iparmq.f'
       INCLUDE 'lapack/util/dlamch.f'
       INCLUDE 'blas/dger.f'
       INCLUDE 'blas/idamax.f'
       INCLUDE 'blas/dswap.f'
       INCLUDE 'blas/dgemm.f'
       INCLUDE 'blas/dgemv.f'
       INCLUDE 'blas/dscal.f'
       INCLUDE 'blas/dtrmv.f'
       INCLUDE 'blas/dtrmm.f'
       INCLUDE 'blas/dtrsm.f'
       INCLUDE 'blas/xerbla.f'

Guthrie M.'s picture

This seems exactly what I'm looking for, however I'm not sure how to "add a directive in the called procedure". The problem occurs in a large section of old Fortran code. The old Fortran (Livermore ODE solver) is very good code but long, about 14000 lines. It's written consciously using integer and real work arrays that occupy the same storage location like this

subroutine example(IWORK,RWORK)

call example(REALarray,REALarray)

I tried creating a module containing the large old Fortran section with "!DEC$ ATTRIBUTES NO_ARG_CHECK :: dummy_arg_name" immediately after the module statement, but it didn't work ,and I received this error message:  "error #7673: The DEC$ ATTRIBUTES NO_ARG_CHECK directive shall appear only in an interface block or module procedure.   [NO_ARG_CHECK]".  Where exactly should I put the "dummy_arg_name" statement?

Any help greatly appreciated,

Thanks

John D B.'s picture

This problem occurs any time a "type" is introduced in to calling sequence. The solution is put procedures into a module. and place the type declaration in to module header and remove it from the procedures.

The following listing of two subroutines demostrates the problem.

subroutine pr_line
!
implicit none
!
type ln_obj
integer :: left
end type ln_obj
!
type(ln_obj) :: ln
!
call pr_parse_line(ln)
!
end subroutine pr_line
!
! ------------------------------------------------------------------
!
subroutine pr_parse_line(ln)
!
implicit none
!
type ln_obj
integer :: left
end type ln_obj
!
type(ln_obj), intent(in) :: ln
!
end subroutine pr_parse_line
!
! ------------------------------------------------------------------

The following module show the get-a-round or perhaps a temporary solution.

module error_6633_module
!
type ln_obj
integer :: left
end type ln_obj

subroutine pr_line
!
implicit none
!
type(ln_obj) :: ln
!
call pr_parse_line(ln)
!
end subroutine pr_line
!
! ------------------------------------------------------------------
!
subroutine pr_parse_line(ln)
!
implicit none
!
type(ln_obj), intent(in) :: ln
!
end subroutine pr_parse_line
!
! ------------------------------------------------------------------

Add a Comment

Have a technical question? Visit our forums. Have site or software product issues? Contact support.