Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

What does this mean?

cryptogram
New Contributor I
549 Views

Got a new computer and decided to replace my old Parallel studio with the new One API stuff:

Microsoft Visual Studio Community 2019
Version 16.10.4
Intel® Fortran Compiler Package ID: w_oneAPI_2021.3.0.306
Intel® Fortran Compiler – toolkit version: 2021.3.0, extension version 19.2.0062.16, Package ID:

And set it to the task of compiler some modelling software that I work with, code that I didn't write.

Oddly, it complains about one routine, but only if I compile a debug version.

 

The error is:

error #8000: There is a conflict between local interface block and external interface block. [CALCULATE_TKE]

and the same thing for several other routines.

 

This involves a recursive subroutine with multiple entry points, and it complains about every

entry point.

 

I've distilled this down into a small example, which I have attached.

If you just want to look, I've also pasted it below.

 

Was hoping someone could tell me what it thinks is wrong, or if this is a compiler bug.

 

RECURSIVE SUBROUTINE CALCULATE_AZ
IMPLICIT NONE
SAVE
INTEGER :: K

k = 1

IF (k .eq.1) THEN
CALL CALCULATE_TKE
ELSEIF (k.eq.2) THEN
CALL CALCULATE_TKE1
ELSE

CALL CALCULATE_AZ0
end if
RETURN

ENTRY CALCULATE_AZ0
k = 2
RETURN

ENTRY CALCULATE_TKE
k = 3
RETURN

ENTRY CALCULATE_TKE1
k = 4
RETURN
END SUBROUTINE CALCULATE_AZ

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
525 Views

This will happen if you compile it twice. The compiler has generated interface blocks for each ENTRY, and is then getting confused on subsequent compiles because the generated interfaces don't really match an ENTRY. I would argue that the compiler should not generate an interface block for an ENTRY, as those are supposed to be for "external procedures".

For now, disable generated interface checking (for this source, anyway). Properties > Fortran > Diagnostics > Check Routine Interfaces > No.

This is a compiler bug - hopefully one of the Intel folk will pick this up.

However... ENTRY is really not a nice thing to use. I'd recommend an internal procedure instead. For example:

RECURSIVE SUBROUTINE CALCULATE_AZ
  IMPLICIT NONE
  SAVE
  INTEGER             :: K
  
  k = 1
  
  IF     (k .eq.1) THEN
    CALL CALCULATE_TKE
  ELSEIF (k.eq.2) THEN
    CALL CALCULATE_TKE1
  ELSE

      CALL CALCULATE_AZ0
   end if      
RETURN
CONTAINS
SUBROUTINE CALCULATE_AZ0
k = 2
RETURN
END SUBROUTINE CALCULATE_AZ0

SUBROUTINE CALCULATE_TKE
   k = 3
  RETURN
END SUBROUTINE CALCULATE_TKE

SUBROUTINE CALCULATE_TKE1
 k = 4
RETURN
END SUBROUTINE CALCULATE_TKE1

END SUBROUTINE CALCULATE_AZ

View solution in original post

0 Kudos
2 Replies
Steve_Lionel
Honored Contributor III
526 Views

This will happen if you compile it twice. The compiler has generated interface blocks for each ENTRY, and is then getting confused on subsequent compiles because the generated interfaces don't really match an ENTRY. I would argue that the compiler should not generate an interface block for an ENTRY, as those are supposed to be for "external procedures".

For now, disable generated interface checking (for this source, anyway). Properties > Fortran > Diagnostics > Check Routine Interfaces > No.

This is a compiler bug - hopefully one of the Intel folk will pick this up.

However... ENTRY is really not a nice thing to use. I'd recommend an internal procedure instead. For example:

RECURSIVE SUBROUTINE CALCULATE_AZ
  IMPLICIT NONE
  SAVE
  INTEGER             :: K
  
  k = 1
  
  IF     (k .eq.1) THEN
    CALL CALCULATE_TKE
  ELSEIF (k.eq.2) THEN
    CALL CALCULATE_TKE1
  ELSE

      CALL CALCULATE_AZ0
   end if      
RETURN
CONTAINS
SUBROUTINE CALCULATE_AZ0
k = 2
RETURN
END SUBROUTINE CALCULATE_AZ0

SUBROUTINE CALCULATE_TKE
   k = 3
  RETURN
END SUBROUTINE CALCULATE_TKE

SUBROUTINE CALCULATE_TKE1
 k = 4
RETURN
END SUBROUTINE CALCULATE_TKE1

END SUBROUTINE CALCULATE_AZ
0 Kudos
cryptogram
New Contributor I
514 Views

I'll pass this along to the custodians of the code and hopefully they will change it so everyone who downloads the model will benefit.

0 Kudos
Reply