topic Re: Another bug with IMPORT and SELECT RANK in Intel® Fortran Compiler

Another bug with IMPORT and SELECT RANK

OP1 — Wed, 26 Jun 2024 19:42:12 GMT

Those posts are turning into an unhealthy obsession with IMPORT these days! A colleague stumbled on the following, which clearly is a compiler bug.

When compiled (as is), the compiler (2024.1.0, both ifx or ifort) returns the message "error #6606: The block construct names must match, and they do not. [SRNK1]"

They DO match, haha.

The code shows how to make that bug go away, and oddly it involves IMPORT again - maybe there is something more serious lurking behind the scenes here as this seems completely unrelated.

MODULE M IMPLICIT NONE (TYPE, EXTERNAL) INTEGER, PARAMETER :: I4 = SELECTED_INT_KIND(9) INTERFACE MODULE SUBROUTINE SUB_M(A) IMPORT, ONLY : I4 IMPLICIT NONE (TYPE, EXTERNAL) INTEGER(KIND = I4), INTENT(IN) :: A(..) END SUBROUTINE END INTERFACE END MODULE M SUBMODULE (M) SUB_M IMPORT, ALL IMPLICIT NONE (TYPE, EXTERNAL) CONTAINS MODULE SUBROUTINE SUB_M(A) ! Will compile if you comment the IMPORT, ONLY statement ! and define I4 locally after IMPLICIT NONE (by uncommenting). ! Will also compile if you comment out the select rank block SRNK1. IMPORT, ONLY : I4 IMPLICIT NONE (TYPE, EXTERNAL) !INTEGER, PARAMETER :: I4 = SELECTED_INT_KIND(9) INTEGER(KIND = I4), INTENT(IN) :: A(..) SRNK1: SELECT RANK (A) RANK (*) END SELECT SRNK1 END SUBROUTINE SUB_M END SUBMODULE SUB_M

Re: Another bug with IMPORT and SELECT RANK

Devorah_H_Intel — Wed, 26 Jun 2024 21:44:00 GMT

Please test with ifx 2024.2
It has been fixed in that version.

Re: Another bug with IMPORT and SELECT RANK

andrew_4619 — Wed, 26 Jun 2024 22:14:18 GMT

Why are the redundant IMPLICIT NONE (TYPE, EXTERNAL) lines in the routines when it is already module wide?

Re: Another bug with IMPORT and SELECT RANK

OP1 — Thu, 27 Jun 2024 00:27:25 GMT

@andrew_4619 See this thread: scope of implicit none in interface block? - Intel Community

Re: Another bug with IMPORT and SELECT RANK

andrew_4619 — Thu, 27 Jun 2024 05:40:56 GMT

Interfaces wasn't part of my point. The implicit statement at line 26 above is redundant as the one at line 18 applies in all the routines in that submodule and given the declaration in the implementation is checked against the interface then in effect to applies within the interface also!

Re: Another bug with IMPORT and SELECT RANK

OP1 — Thu, 27 Jun 2024 14:06:35 GMT

Your comment regarding the unnecessary duplication of the IMPLICIT NONE statement is correct, technically (because IMPLICIT NONE is the desired behavior for both module and contained procedure in the original post's code), but note that in general a contained procedure can still have its own IMPLICIT statement(s). Consider the example shown below

MODULE M CONTAINS SUBROUTINE S1(I) !IMPLICIT REAL (I) ! This line needs to be uncommented for ! the code to compile. WRITE(*, *) I END SUBROUTINE S1 END MODULE M PROGRAM P USE M IMPLICIT NONE (TYPE, EXTERNAL) REAL :: I CALL S1(I) END PROGRAM P

Our policy is to avoid having to finesse those IMPORT statements and not try to be clever with them. We require those IMPORT statements everywhere they are allowed - for peace of mind. It seems this is also your strategy, in this thread (https://community.intel.com/t5/Intel-Fortran-Compiler/The-IMPLICIT-NONE-issue-drags-on/td-p/1109569 ) you posted:

@andrew_4619 wrote:
From a personal point of view I put implicit none absolutely everywhere often in a redundant way and that way I feel happy that my trousers will not fall down as I have both belt and braces.