Another (!) bug with IMPORT

[OP1]

As shown, the following code does not compile with ifx 2026.0.0 (Debug and Release) on Windows.

MODULE M
IMPLICIT NONE
TYPE :: T
    CONTAINS 
    PROCEDURE, NOPASS :: S => T_S
    ! PROCEDURE, NOPASS :: SOME_OTHER_BINDING_NAME => T_S
END TYPE T
INTERFACE
    MODULE SUBROUTINE T_S
    END SUBROUTINE T_S
END INTERFACE
END MODULE M
 
 
MODULE N
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S
    END SUBROUTINE S
END INTERFACE
END MODULE N

 
SUBMODULE (N) S
USE :: M, ONLY : T
IMPORT, ALL
IMPLICIT NONE
CONTAINS
MODULE SUBROUTINE S
END SUBROUTINE S
END SUBMODULE S

The compiler erroneously claims that on line 26:

error #8847: A use-associated entity from module M conflicts with a host-associated entity explicitly made accessible by an IMPORT statement in the same scope.   [S]

 This does not make any sense at all, since S is simply a binding name for a procedure bound to the derived type T.

The code will compile if you comment out line 5 and uncomment line 6 (essentially, using a different binding name that does not "collide" with S).

Or, the code will compile if lines 5 and 6 are left as they are and line 25 is commented out.

[Shiquan_Su]

Hi,

I think the error message said the MODULE SUBROUTINE S in module N is conflicting with the procedure S (pointing to MODULE SUBROUTINE T_S ) in module M.

I edited your code as follows, and it passes the compilation:

$ cat test.f90
MODULE M
IMPLICIT NONE
TYPE :: T
CONTAINS
PROCEDURE, NOPASS :: S => T_S
! PROCEDURE, NOPASS :: SOME_OTHER_BINDING_NAME => T_S
END TYPE T
INTERFACE
MODULE SUBROUTINE T_S
END SUBROUTINE T_S
END INTERFACE
END MODULE M

MODULE N
IMPLICIT NONE
INTERFACE
MODULE SUBROUTINE S_avoid_conflict_M
END SUBROUTINE S_avoid_conflict_M
END INTERFACE
END MODULE N

SUBMODULE (N) S1
USE :: M, ONLY : T
IMPORT, ALL
IMPLICIT NONE
!CONTAINS
INTERFACE
MODULE SUBROUTINE S
END SUBROUTINE S
END INTERFACE
END SUBMODULE S1
$ cat runme.sh
#!/bin/bash
module purge
module load intel/oneapi/2026.0
ifx -c test.f90
$ . ./runme.sh
$

[OP1]

@Shiquan_Su , I suspect you miss the point here. The issue with IMPORT, ALL is not due to an interface in module N having the same name as a module subroutine in submodule M. That particular scenario is legitimate, and you can convince yourself of its validity by compiling the simple example here, which does not trigger any compiler error (as expected):

MODULE N
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S
    END SUBROUTINE S
END INTERFACE
END MODULE N
 
SUBMODULE (N) S
IMPORT, ALL
IMPLICIT NONE
CONTAINS
MODULE SUBROUTINE S
END SUBROUTINE S
END SUBMODULE S

The compiler error I am reporting has a different nature: for some reason, the compiler thinks that the BINDING NAME S for the procedure T_S of the derived type T in module M conflicts with the module subroutine S in submodule S. This is wrong, there is no collision here.

[Shiquan_Su]

This is the current situation of the implementation. We suggest you remove the "IMPORT, ALL" from the "SUBMODULE (N) S".
Without IMPORT, ALL, the submodule can still access module N's entities (including the declaration of S) through implicit host association.
Host association means that everything declared in the parent module (N) is automatically accessible in the submodule - you don't need IMPORT for basic access.
Here's the key difference:

SUBMODULE (N) S
USE :: M, ONLY : T
! No IMPORT statement
IMPLICIT NONE
CONTAINS
MODULE SUBROUTINE S
print *, "in submodule S module subroutine S"
END SUBROUTINE S
END SUBMODULE S

In this case:
- The submodule is implementing the module subroutine S that was declared in N
- It doesn't need to explicitly "import" the declaration - it knows about it through host association
- The implementation just provides the body for the interface declared in module N

When do you need IMPORT?

IMPORT is mainly needed in interface bodies or when you want to make host association explicit (to resolve potential ambiguities or for clarity). For example:

INTERFACE
MODULE SUBROUTINE some_proc(x)
IMPORT :: some_type ! Need IMPORT here to use host's some_type
TYPE(some_type) :: x
END SUBROUTINE
END INTERFACE

The conflict with IMPORT, ALL:

When you add IMPORT, ALL, it makes the host association explicit, and the compiler then checks for conflicts with USE-associated names. That's why the error occurs - without it, the implicit host association doesn't trigger the same conflict check.

You may try out the following example:

$ cat runme.sh
#!/bin/bash
## Please also check the Stack Overflow post, the import statement can only be in interface scope in Fortran 2008, but is extended to be allowed in any scoping unit that has a host scoping unit, such as module procedures within a submodule in Fortran 2018
## https://stackoverflow.com/questions/67514373/import-statement-within-module-procedures
module purge
module load intel/oneapi/2026.0
ifx -c test.f90
rm test.o
ifx test.f90 submod_m.f90 driver2.f90 -o driver2
./driver2

rm ./driver2
gfortran --version
gfortran test.f90 submod_m.f90 driver2.f90 -o driver2
./driver2

$ cat test.f90
MODULE M
IMPLICIT NONE
TYPE :: T
CONTAINS
PROCEDURE, NOPASS :: S => T_S
! PROCEDURE, NOPASS :: SOME_OTHER_BINDING_NAME => T_S
END TYPE T
INTERFACE
MODULE SUBROUTINE T_S
END SUBROUTINE T_S
END INTERFACE
END MODULE M

MODULE N
IMPLICIT NONE
INTERFACE
MODULE SUBROUTINE S
END SUBROUTINE S
END INTERFACE
END MODULE N

SUBMODULE (N) S
USE :: M, ONLY : T
!IMPORT, ALL  !! implicit host association in submodule to bring in parent module entities, no need to "IMPORT". The IMPORT makes the host association explicit and triggers checks for conflicts with USE-associated names
IMPLICIT NONE

CONTAINS
MODULE SUBROUTINE S
IMPORT, ALL
print *, "in submodule S module subroutine S"
END SUBROUTINE S
END SUBMODULE S

$ cat submod_m.f90
SUBMODULE (M) M_impl
IMPLICIT NONE
CONTAINS
MODULE SUBROUTINE T_S
print *, "in module M's T_S subroutine"
END SUBROUTINE T_S
END SUBMODULE M_impl
shiquans@ortce-skl21:/scratch/users/shiquans/home_backup-20260505/osc_06873441$ cat driver2.f90
PROGRAM driver2
USE :: M
USE :: N
IMPLICIT NONE

TYPE(T) :: my_t

print *, "=== Testing M's S (type-bound procedure) ==="
CALL my_t%S()

print *, ""
print *, "=== Testing N's S (module subroutine from submodule) ==="
CALL S()

print *, ""
print *, "Driver2 program completed successfully"

END PROGRAM driver2

$ . ./runme.sh
=== Testing M's S (type-bound procedure) ===
in module M's T_S subroutine

=== Testing N's S (module subroutine from submodule) ===
in submodule S module subroutine S

Driver2 program completed successfully
GNU Fortran (Ubuntu 13.2.0-23ubuntu4) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

test.f90:30:25:

30 | MODULE SUBROUTINE S
| 1
Error: Name ‘s’ at (1) is an ambiguous reference to ‘n.s’ from current program unit
test.f90:31:21:

31 | IMPORT, ALL
| 1
Error: IMPORT statement at (1) only permitted in an INTERFACE body
test.f90:32:59:

32 | print *, "in submodule S module subroutine S"
| 1
Error: Unexpected WRITE statement in CONTAINS section at (1)
test.f90:33:9:

33 | END SUBROUTINE S
| 1
Error: Expecting END SUBMODULE statement at (1)
-bash: ./driver2: No such file or directory

[OP1]

@Shiquan_Su, there is a lot to unpack in your post, but I believe (respectfully) that your analysis is incorrect.

First, let me ask you to consider the following code:

MODULE N
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S
    END SUBROUTINE S
END INTERFACE
INTEGER :: X
END MODULE N

 
SUBMODULE (N) S
IMPORT :: S, X
IMPLICIT NONE
INTEGER :: X
CONTAINS
    MODULE SUBROUTINE S
    END SUBROUTINE S
END SUBMODULE S

When compiled (with the latest ifx compiler, 2026.0.0), we get the error: 

error #8855: An entity whose name appears as an import-name or which is made accessible by an IMPORT,ALL statement may not be redeclared   [X]

This does make sense: there is indeed a conflict between X (in module N) and the identically named variable X in submodule S, and this conflict is detected because of the IMPORT statement on line 12.

But let me ask you then: why didn't the compiler also complain about the (seemingly similar) situation with S? After all, there is an interface to the module subroutine S in N, and the body (implementation of that procedure) is in S! I believe that it's because the treatment of interfaces to module procedures in a scoping unit is different than that of other 'entities'.

Next: if we go back to the original example I submitted, please appreciate that the compiler behavior I described is toggled on or off by commenting or uncommenting lines 5 and 6; these lines have nothing to do with the IMPORT issue you describe, because the scope of a binding name is that of a derived type, and it should not 'leak' into the module.