Are INTEGER and INTEGER(KIND=4) type compatible in IFORT?

[avinashs]

In a particular application where I am compiling a fixed format Fortran 66/77 subroutine along with Fortran 90 supporting programs from the command line, the ifort compiler aborts with an error complaining that there is a type mismatch between corresponding INTEGER and DOUBLE PRECISION arguments passed from F77 to F90 at the locations where F90 subroutines are invoked from the .F subroutine. In the F90 subprograms, those arguments are declared as INTEGER(KIND = 4) and REAL(KIND = 8).  I thought that they were equivalent and have not had that problem in other projects built within the MSVS framework. Is there a compiler setting that can overcome this error? I will note that changing all declarations from INTEGER(KIND = 4) to INTEGER and REAL(KIND = to DOUBLE PRECISION in the F90 subprograms fixed the error.

[mecej4]

The thread title does not match the description that you gave. The description itself is quite ambiguous, and it is not clear whether you expect you expect INTEGER and INTEGER*4 to be interchangeable (which they are, if default INTEGER is 4-byte), or you expect INTEGER and REAL types to be interchangeable. 

Please show an example of code where the compiler issues an error message.

Whether the source code is in fixed (.F) or free (.F90) format is irrelevant to your issue. Default REAL and INTEGER are of the same length (4 bytes). However, the representations of REAL and INTEGER are quite different, and passing arguments that are not matched w.r.t. type is bound to cause errors, except in one special case: when the actual argument is a scratch array being provided to the subroutine being called, and that subroutine does not use any of the previous contents of that scratch array.

Here is a small program to illustrate the incompatibility between INTEGER and REAL, even though each occupies 4 bytes.

program kinds
implicit none
integer i
real r
i = 2
r = 2.0
call sub(i,r)
end program

subroutine sub(r,i)
implicit none
integer i
real r
print *,i,r
return
end subroutine

You will have to put the two program units into separate files to bypass the compiler's argument checking. The program output should be instructive.

So far, the mismatch is w.r.t. type, but those mismatched types occupy four bytes each. If you change REAL to DOUBLE PRECISION in the program, things are bound to get even worse. Again, however, if all you are passing is uninitialized scratch space, the mismatch may not matter as far as program execution is concerned, but it is poor programming practice to plant such seeds of confusion and errors in source codes.

[Steve_Lionel]

It could be that you added a compiler option to change the default integer kind.