- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The fix is coming in the next Intel Fortran Compiler update 2021.7
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page