Community
cancel
Showing results for 
Search instead for 
Did you mean: 
OP1
Novice
221 Views

Scope of USE statement in an INTERFACE block

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
Valued Contributor III
187 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
Novice
180 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
Valued Contributor III
167 Views

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

Steve_Lionel
Black Belt Retired Employee
163 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
Novice
128 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 I
116 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 I
109 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
93 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.

 
Ronald_G_Intel
Moderator
55 Views

Bug ID isCMPLRIL0-33635