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

Scope of USE statement in an INTERFACE block

OP1
New Contributor I
419 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
9 Replies
andrew_4619
Honored Contributor I
385 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!  

OP1
New Contributor I
378 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.

andrew_4619
Honored Contributor I
365 Views

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

Steve_Lionel
Black Belt Retired Employee
361 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.

OP1
New Contributor I
326 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.

FortranFan
Honored Contributor II
314 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>
FortranFan
Honored Contributor II
307 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

 

Steve_Lionel
Black Belt Retired Employee
291 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.

 
Ron_Green
Moderator
253 Views
Reply