"There is a conflict between local interface block and external..."

[OP1]

I have scratched my head yesterday over an intermittent build issue that was causing lots of headaches - in a fairly large code. I am getting the "conflict between local interface block and external interface block" error message.

I use IVF 10 and VS2005.

Here is a small test code that reproduces this error. Once built from scratch, the code will run. Then, if I try to compile (immediately after the successful build) the main subroutine MY_PROG I get the error message. My larger code exhibits the same behavior (more unpredictably though - as I suspect this interface conflict somehow depends on the compile order).

The main subroutine:

PROGRAM MY_PROG
USE MY_MODULE
IMPLICIT NONE
INTERFACE
SUBROUTINE MY_SUB(T)
USE MY_MODULE
IMPLICIT NONE
TYPE(MY_TYPE),INTENT(IN),OPTIONAL :: T
END SUBROUTINE MY_SUB
END INTERFACE
TYPE(MY_TYPE) T
T%I = 12
CALL MY_SUB(T)
END PROGRAM MY_PROG

Here is the module:

MODULE MY_MODULE
IMPLICIT NONE
TYPE MY_TYPE
INTEGER I
END TYPE MY_TYPE
END MODULE MY_MODULE

Here is a subroutine:

SUBROUTINE MY_SUB(T)
USE MY_MODULE
IMPLICIT NONE
TYPE(MY_TYPE),INTENT(IN),OPTIONAL :: T
IF (PRESENT(T)) THEN
WRITE(*,*) T%I
ENDIF
END SUBROUTINE MY_SUB


How do I get around this? Isn't this bizarre that a clean build works and then a simple additional compile triggers this error? Is this a bug? My code makes a fairly intensive usage of explicit interfaces and types. I didn't bump into this issue until yesterday. I just added one subroutine that looked innocently like many others declared the same way (explicit interface block, the subroutines use a derivedtype declared in a module also used by their calling subroutines). That was the straw that broke the camel's backI guess.

Thanks for your help,

Olivier

[Steven_L_Intel1]

Turn off generated interface checking. You've encountered a bug that was fixed quite a while ago. I recommend using a current compiler.

[taherehfor]

Quoting - Steve Lionel (Intel)

Turn off generated interface checking. You've encountered a bug that was fixed quite a while ago. I recommend using a current compiler.

Hi,
How can I turn off the generated interface checking. I've got the same error, but in my case I'm building an example code that I converted from *.f to *.f90, and don't know it's because of that or not.

Thanks in advance,
Tahereh

[Steven_L_Intel1]

Which compiler version are you using? Simply changing source forms should have no effect on this.

To disable generated interface checking, turn off the options "Generate interface blocks" and "Check routine interfaces". Currently, these are on the Diagnostics page, but in earlier releases one of them was under External Procedures, I think.

[taherehfor]

I'm using Intel visual Fortran 11.0.072 and microsfot visual studio 2005 professional edition and my machine type is 64-bit. ( I have also Intel Fortran compiler 10.1.011 installed on my pc , but I don't know what's the difference between this and the visual one!)

I have two question here:
1-everytime I define a new project, I have to define a new active solution platform, how can I do sth that x64 becomes default? both for the configuration manager and for the path, include, and lib settings.

2-how can I compile files with .F extension? do I need to convert them first or IVF can takes care of that?

Thanks,
Tahereh

[Steven_L_Intel1]

1 - You can't, as far as I know. I think this is a poor design decision of Microsoft's.
2- Files with a .F extension will be compiled automatically as fixed-form source. If you want the preprocessor run on them, you must enable the "Use fpp" property under Preprocessing.

As for the versions, we just changed how it appears in the Start menu. Both are the Intel Visual Fortran product.