topic Re: Bug with IMPORT statement in submodule in Intel® Fortran Compiler

Bug with IMPORT statement in submodule

OP1 — Tue, 11 Jun 2024 21:44:40 GMT

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

Re: Bug with IMPORT statement in submodule

Ron_Green — Tue, 11 Jun 2024 23:12:10 GMT

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.

Re: Bug with IMPORT statement in submodule

andrew_4619 — Wed, 12 Jun 2024 08:18:33 GMT

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

Re: Bug with IMPORT statement in submodule

Ron_Green — Wed, 12 Jun 2024 20:02:35 GMT

@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.

Re: Bug with IMPORT statement in submodule

FortranFan — Wed, 12 Jun 2024 21:17:15 GMT

@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>

Re: Bug with IMPORT statement in submodule

OP1 — Wed, 22 Apr 2026 21:48:39 GMT

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?

Re: Bug with IMPORT statement in submodule

Shiquan_Su — Tue, 28 Apr 2026 14:36:52 GMT

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

Re:Bug with IMPORT statement in submodule

Igor_V_Intel — Thu, 30 Apr 2026 15:39:06 GMT

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).