Another bug with IMPORT and SELECT RANK

[OP1]

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

[Devorah_H_Intel · Accepted solution]

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

[andrew_4619]

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

[OP1]

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

[andrew_4619]

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!

[OP1]

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.