How to skip error message: "error #6633: The type of the actual argument differs from the type of the dummy argument."

[spakintel]

Hi,

I'm trying to compile a program package using IVF 11.1. During compilation, I get many error massages, all saying same thing:

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

I know that it is a new feature in IVF 11.1 to find type mismatch between the actual and dummy arguments. If I compile the code using other compilers, I don't get such errors. I don't want to modify the code, as its a giant code and it would too tedious to correct all the affected subroutines. I just need a simple compiler flag to force the ifort to ignore all the type mismatches between the arguments.

Any idea?

Thanks.

[mecej4]

Please provide more details. With the Linux-x64 version of IFort 11.1 (l_cprof_p_11.1.072), for the following buggy code (tst.f),

[fxfortran]      subroutine sub(i)
      integer i
      i=2*i-1
      return
      end

      program tst
      real x
      x=2
      call sub(x)
      write(*,*)x
      stop
      end
[/fxfortran]

I find the following

[bash]~/LANG> ifort -C tst.f
~/LANG> ./a.out
 NaN
[/bash]

On the other hand, if you have good code, with explicit interfaces; or two calls to the same subroutine/function from one program unit with inconsistent argument lists, the compiler would be justified in flagging the error.

Your claim, "If I compile the code using other compilers, I don't get such errors" is overly broad and, fortunately for most of us, not true. It is one thing to ask how to coax a compiler to accept code that is not standards-compliant; it is quite another to fault the compiler for doing a good thing!

[spakintel]

OK, let me show you piece of the code which causes the above error message:

[bash]      SUBROUTINE CFFTB (N,C,WSAVE)                                              
      IMPLICIT REAL*8     (A-H,O-Z)
      DIMENSION       C(*)       ,WSAVE(*)                                      
!                                                                               
      IF (N .EQ. 1) RETURN                                                      
      IW1 = N+N+1                                                               
      IW2 = IW1+N+N                                                             
      CALL CFFTB1 (N,C,WSAVE,WSAVE(IW1),WSAVE(IW2))                             
      RETURN                                                                    
      END                                                                       
      SUBROUTINE CFFTB1 (N,C,CH,WA,IFAC)                                        
      IMPLICIT REAL*8     (A-H,O-Z)
      DIMENSION       CH(*)      ,C(*)       ,WA(*)      ,IFAC(*)               
      NF = IFAC(2)                                                              
      NA = 0                                                                    
      L1 = 1                                                                    
      IW = 1                                                                    
      DO 116 K1=1,NF [/bash]

And this is the error that I get from this part:

[bash]C:UsersMYWINDocumentsUtilityBoltzTraPSRC_BoltzTraP110c3fft.f90(250): error #6633: The type of the actual argument differs from the type of the dummy argument.   [WSAVE]
compilation aborted for C:UsersMYWINDocumentsUtilityBoltzTraPSRC_BoltzTraP110c3fft.f90 (code 1)[/bash]

As you see, the message refers to the type mismatch between WSAVE and IFAC arrays. The former is REAL(8) while the latter is Integer type. I use the Windows version of intel fortran compiler (11.1.65). However, when I compile the same code using the Mac OSX version of ifort (11.1.76), I don't see any error like this.

[TimP]

Are you complaining about /gen-interfaces being set by default in Visual Studio? Compaq Fortran used to have such a check (within a single file) as a default even when compiling by command line, so the idea of turning off such warnings for legacy code is hardly new-fangled. This code looks like it came from the 60's, when such non-standard stuff was quite likely to break between different brands of compilers.

[Steven_L_Intel1]

You are seeing the error on Windows because the default for a Visual Studio project is to enable the "Check Routine Interfaces" option. This is not the default when used from the command line.

What your code does is VERY dangerous and is likely to give incorrect results. You should be thankful that the compiler alerted you to the coding error. Some possibilities are having the value change when you pass it, or getting zero assigned when you wanted a small integer.

If you like using chainsaws with the blade guard removed, right click on the project, select Properties > Fortran > DIagnostics and set "Check Routine Interfaces" to No.

[mecej4]

This sort of code was quite common even during the 1980s. And, it is less dangerous than one may think: if the only argument type mismatches are for uninitialized work-space, as in this case, and if the program worked before, it will probably do OK.

However, this is a good opportunity to fix the code. In fact, using the allocatable array features of Fortran 90, the OP should be able to do away with the extra workspace arguments, putting in local allocated arrays in their place.

To the OP: if you use the command-line, make sure that the options in IFORT.CFG (in the compiler's BIN directory) are not set to catch this class of error.

[nvaneck]

Sometimes you need to do this. For example, in mystat package MicrOsirisinput data items can be of any mode and length, requiring mis-matches for conversion and retrieval. Some work-arounds are possible, but not all.

In other cases I have routines that need to take arguments in integer or real mode, e.g., a cross tab program thatneeds to work with integer data or real data.Without being able to pass the arguments twice in different modes, I would have to replicate a tremendous amount of code, making maintenance a nightmare. Some of it can be gotten arround by equivalencing data, but of course, that is frowned upon today and prevents dynamic allocation. Changing everything to a common real*8 formatmight get around it, but a costly price in proceesing time and I/O time for large datasets (e.g., 100,000records of6000 variables)that need multiple passes but operate with with nominal and ordinal data with some interval data, as well as inflated disk-space requirements.

[spakintel]

Thanks Steve,

As usual, your reply was helpful. After disabling the"Check Routine Interfaces", compilation went through without a hitch! I know that the code may have a non-standard routine, but I don't really want to touch any of its subroutines, as it's a relatively big package.