- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page