Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Scope of USE statement in an INTERFACE block

OP1
New Contributor II
941 Views

I am a bit confused by the following code; namely, the lack of a USE statement in the interface to S2. Shouldn't this trigger a compiler error? What is the exact scope of a USE statement in an interface block?

MODULE M
IMPLICIT NONE
    TYPE T
    END TYPE T
END MODULE M

MODULE N
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S1(V1)
    USE M
    IMPLICIT NONE
    TYPE(T) :: V1
    END SUBROUTINE S1
    MODULE SUBROUTINE S2(V2)
    IMPLICIT NONE
    TYPE(T) :: V2 ! The compiler does not complain about T.
    END SUBROUTINE S2
END INTERFACE
INTERFACE
    MODULE SUBROUTINE S3(V3)
    IMPLICIT NONE
    TYPE(T) :: V3 ! The compiler does not complain about T.
    END SUBROUTINE S3
END INTERFACE
TYPE(T) :: W ! The compiler complains that T has not been declared
END MODULE N

 

0 Kudos
1 Solution
Devorah_H_Intel
Moderator
515 Views

The fix is coming in the next Intel Fortran Compiler update 2021.7

View solution in original post

0 Kudos
10 Replies
andrew_4619
Honored Contributor II
907 Views

That would be a bug I think. The Use M is leaking into the scope of module N, the scope should only ne the interface. Note that if you move USE m  into S3 your get all the errors for S1 and S2!  

0 Kudos
OP1
New Contributor II
900 Views

Thanks for confirming this. I reported this bug through Intel's Online Service Center. Note that this reproducers was compiled with PSXE 20U4 on Windows.

0 Kudos
andrew_4619
Honored Contributor II
887 Views

I used Intel® Fortran Compiler Classic 2021.1.1 [Intel(R) 64]

0 Kudos
Steve_Lionel
Honored Contributor III
883 Views

I discuss the use of USE in INTERFACE blocks in Domestic or Imported? - Doctor Fortran (stevelionel.com)

I agree that the lack of error for the declaration of V3 is a bug.

0 Kudos
OP1
New Contributor II
848 Views

Steve,

I read your blog post... but I am not sure it explains the difference in behavior when the INTERFACE blocks is made of MODULE SUBROUTINE/FUNCTION statements (which do not require IMPORTing module objects) , instead of SUBROUTINE/FUNCTION statements (which do require IMPORTing module objects).

And I am still not sure I understand why the USE M statement on line 11 (within S1 interface) is 'visible' by S2. To me this is a bug - but I'd be glad to be corrected of course.

0 Kudos
FortranFan
Honored Contributor II
836 Views
@OP1 wrote:
.. not sure I understand why the USE M statement on line 11 (within S1 interface) is 'visible' by S2. To me this is a bug - but I'd be glad to be corrected of course.

For whatever it's worth, I agree the case with S2 is also a bug.  I suggest you submit a support request with Intel if you are able to and have that team review it.  The expected behavior is as shown by gfortran:

MODULE M
IMPLICIT NONE
    TYPE T
    END TYPE T
END MODULE M

MODULE N
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S1(V1)
    USE M
    IMPLICIT NONE
    TYPE(T) :: V1
    END SUBROUTINE S1
    MODULE SUBROUTINE S2(V2)
    IMPLICIT NONE
    TYPE(T) :: V2
    END SUBROUTINE S2
END INTERFACE
END MODULE N
C:\Temp>gfortran -c n.f90
n.f90:17:12:

   17 |     TYPE(T) :: V2
      |            1
Error: Derived type 't' at (1) is being used before it is defined
n.f90:15:27:

   15 |     MODULE SUBROUTINE S2(V2)
      |                           1
Error: Symbol 'v2' at (1) has no IMPLICIT type

C:\Temp>
0 Kudos
FortranFan
Honored Contributor II
829 Views
OP1 wrote:
Steve,

I read your blog post... but I am not sure it explains the difference in behavior when the INTERFACE blocks is made of MODULE SUBROUTINE/FUNCTION statements (which do not require IMPORTing module objects) , instead of SUBROUTINE/FUNCTION statements (which do require IMPORTing module objects). ..

 

The blogpost by @Steve_Lionel appears to predate the Fortran 2008 feature of MODULE SUBROUTINEs (and MODULE FUNCTIONs) that help facilitate the SUBMODULEs feature.

MODULE SUBROUTINEs (and MODULE FUNCTIONs), as pointed out by OP1, have access to host entities in their INTERFACE scope.

To state the obvious, USE association to M at the module level in N would be a way around this.  But it will be great when Intel Fortran compiler diagnoses the issue presented by the code in the original post:

MODULE M
IMPLICIT NONE
    TYPE T
    END TYPE T
END MODULE M

MODULE N
    USE M !<-- Module N "use-associates" the module M and its public entities
IMPLICIT NONE
INTERFACE
    MODULE SUBROUTINE S1(V1)
    IMPLICIT NONE
    TYPE(T) :: V1
    END SUBROUTINE S1
    MODULE SUBROUTINE S2(V2)
    IMPLICIT NONE
    TYPE(T) :: V2
    END SUBROUTINE S2
END INTERFACE
INTERFACE
    MODULE SUBROUTINE S3(V3)
    IMPLICIT NONE
    TYPE(T) :: V3
    END SUBROUTINE S3
END INTERFACE
TYPE(T) :: W
END MODULE N

 

0 Kudos
Steve_Lionel
Honored Contributor III
813 Views

Indeed, I wrote that blog post in 2006. Since then, IMPORT has been enhanced with ,ALL and ,NONE keywords, and it operates differently in contexts that did not exist in F2003 (such as BLOCK constructs.)  I have an ever-growing list of topics to revisit.

Sometimes the standards committee must "stand on its head" to avoid backward compatibility problems with previous standards, as we really, really, really hate to break existing code. The result is sometimes oddly constructed new features and internal inconsistencies.

 
0 Kudos
Ron_Green
Moderator
775 Views
0 Kudos
Devorah_H_Intel
Moderator
516 Views

The fix is coming in the next Intel Fortran Compiler update 2021.7

0 Kudos
Reply