Bug with IMPORT statement in submodule

[OP1]

The following code triggers a spurious compiler error.

My understanding is that the variable J is "the name of one or more entities accessible in the host scoping unit" (per the documentation) and therefore its use in the IMPORT statement should be valid.

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER, PARAMETER :: J = 1
END MODULE M


MODULE N
USE M
IMPLICIT NONE (TYPE, EXTERNAL)
INTERFACE
    MODULE SUBROUTINE S
    END SUBROUTINE S
END INTERFACE
END MODULE N


SUBMODULE (N) S
IMPORT, ONLY : S, J   ! This line triggers a compiler error.
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE S
    IMPLICIT NONE (TYPE, EXTERNAL)
    WRITE(*, *) J
    END SUBROUTINE S
END SUBMODULE S

[Ron_Green]

I'll have to get our Standards members to look at this one.  First, ifx is in agreement with gfortran 13 and Nag that this IMPORT is illegal.  That is not to say that all 3 are right.  Perhaps all 3 compilers are getting this wrong.  Surely this deserves a more in-depth analysis with the Standard experts.  @OP1 your code is usually conformant so I'm inclined to side with you that this should be legal.  My reading would suggest the IMPORT has to go in the INTERFACE in MODULE N.  But with submodules my intuition may be flawed.

[andrew_4619]

F2018 had significant changes in IMPORT and from my initial reading I think it may be valid.

[Ron_Green]

@OP1 Jon Steidel agrees with you, it seems valid.  I will start a bug report for ifx.  His further analysis

Fortran 2018 expanded the use of the IMPORT statement to allow it in BLOCKs, internal procedures, and module procedures. There is a constraint

                C8100     An IMPORT statement shall not appear in the scoping unit of a main-program, external-subprogram, module, or block-data

which does not prohibit it in a submodule.  Then there is another constraint

                C8103      IMPORT, NONE shall not appear in the scoping unit of a submodule

So, it seems that this test case is valid.  I wrote a couple simple tests and it appears NAG and gfortran have not yet implemented this F2018 feature.  

[FortranFan]

@Ron_Green ,

@andrew_4619 and Jon Steidel pointed you in the right direction.  And you are very likely correct in that both gfortran and NAG Fortran might yet have to catch up to this Fortran 2018 facility.  But here I thought I saw a blurb some place NAG Fortran is now conformant with Fortran 2018; if so, this is likely a bug in that compiler.

Anyways, you can pass this simpler variant to the Intel Fortran team which is processed as expected by IFX 2024.1.0 version (and that is really cool).  So the issue here is very likely when it comes to entities in a MODULE that are introduced via USE association rather than declared in the module itself.

MODULE N
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER, PARAMETER :: J = 1
INTERFACE
    MODULE SUBROUTINE S
    END SUBROUTINE S
END INTERFACE
END MODULE N


SUBMODULE (N) S
IMPORT, ONLY : S, J
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE S
    IMPLICIT NONE (TYPE, EXTERNAL)
    WRITE(*, *) J
    END SUBROUTINE S
END SUBMODULE S

C:\temp>ifx /c /standard-semantics /free n.f
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.


C:\temp>

[OP1]

This confirmed bug is still present in 2025.3.2. Was a bug report ever written for this, or did it fall in a crack somewhere?

[Shiquan_Su]

I confirmed the original code example still meets an error during compilation. I escalate this to the developer.

[Igor_V_Intel]

I don't think that it is a compiler bug. Key rule that decides everything is C897 from F2018, §8.8 (IMPORT statement):

C897 (R867): Each import-name shall be the name of an entity in the host scoping unit.

So, the question here is J an entity of the host scoping unit of the submodule?

If yes then IMPORT, ONLY : J is legal. If no, then it is required to be rejected by the compiler.

In the second example, J is declared directly in MODULE N. 

J is an entity of the host scoping unit and IMPORT, ONLY : S, J satisfies C897

ifx doesn't emit an error in this case.

In your original case (first example), J comes from USE M. J is not declared in MODULE N and is declared in MODULE M.

MODULE N merely has USE association with M. Since IMPORT only applies to host association, not USE association, J does not satisfy C897 in this case. Note that S is still allowed since it is declared in MODULE N (via the interface body).

[OP1]

@Igor_V_Intel you interpretation seems to be at odd with this slightly modified code, which shows it is necessary to use an IMPORT statement for the interface of procedure S2.

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
INTEGER, PARAMETER :: J = 1
END MODULE M


MODULE N
USE M
IMPLICIT NONE (TYPE, EXTERNAL)
INTERFACE
    MODULE SUBROUTINE S1
    END SUBROUTINE S1
END INTERFACE
INTERFACE
    SUBROUTINE S2(X)
    IMPORT, ONLY : J  ! Commenting this line will trigger an error.
    IMPLICIT NONE (TYPE, EXTERNAL)
    INTEGER :: X(J)
    END SUBROUTINE S2
END INTERFACE
END MODULE N


SUBMODULE (N) S1
!IMPORT, ONLY : S1, J   ! Uncommenting this line triggers a compiler error.
IMPLICIT NONE (TYPE, EXTERNAL)
CONTAINS
    MODULE SUBROUTINE S1
    IMPLICIT NONE (TYPE, EXTERNAL)
    WRITE(*, *) J
    END SUBROUTINE S1
END SUBMODULE S1

An IMPORT statement applied to entities that are explicitly defined in the host as well as to entities that are accessible through use association. In my opinion the first case (in the original post) is still a bug. 

[andrew_4619]

C897 (R867): Each import-name shall be the name of an entity in the host scoping unit.

To me that would include both USE and HOST defined names as they are all in the HOST name space and C997 it is not more specific.