- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following code triggers (what I believe to be) a bug with both the latest versions of ifort and ifx:
Note that the compilers do not complain when the module M is not used and instead the variables A and B are declared in P.
MODULE M
IMPLICIT NONE
REAL :: A, B
END MODULE M
PROGRAM P
USE M
IMPLICIT NONE
!REAL :: A, B
EQUIVALENCE (A, B)
END PROGRAM P
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With COMMON, each program unit had its own declaration of the COMMON, and EQUIVALENCE within the COMMON was fine. Of course, you were responsible for making sure that the overall length of the named COMMON was the same across all program units, and ideally, use of EQUIVALENCE didn't change the meaning of the variables in the block. The recommended practice was to put all the COMMON and EQUIVALENCE declarations in an include file, and include this everywhere. (Note that INCLUDE wasn't standard until Fortran 90, though it did appear in MIL-STD-1753.) Any DATA statements should be confined to a BLOCK DATA subprogram that included the COMMON definitions.
If replacing the COMMON with module variables, any EQUIVALENCE would need to be in the same module where the variables were declared. Maybe that is the issue you ran into?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What exactly do you think the bug is?
D:\Projects>ifort -c t.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.7.1 Build 20221019_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
t.f90(10): error #6401: The attributes of this name conflict with those made accessible by a USE statement. [A]
EQUIVALENCE (A, B)
-------------^
t.f90(10): error #6401: The attributes of this name conflict with those made accessible by a USE statement. [B]
EQUIVALENCE (A, B)
----------------^
compilation aborted for t.f90 (code 1)
For comparison, here is NAG Fortran:
D:\Projects>nagfor -c t.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7114
Error: t.f90, line 10: Redeclaration of symbol A from USEd module M
detected at (@A
Error: t.f90, line 10: Redeclaration of symbol B from USEd module M
detected at ,@B
[NAG Fortran Compiler pass 1 error termination, 2 errors]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve - I understand what is going on now, you're right this is the expected behavior.
This came up during an exercise of porting a (very) old code with COMMON blocks galore and replacing those with modules. But now I am a bit puzzled about how that old code worked in the first place, ha ha. I need to take a deeper look at this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With COMMON, each program unit had its own declaration of the COMMON, and EQUIVALENCE within the COMMON was fine. Of course, you were responsible for making sure that the overall length of the named COMMON was the same across all program units, and ideally, use of EQUIVALENCE didn't change the meaning of the variables in the block. The recommended practice was to put all the COMMON and EQUIVALENCE declarations in an include file, and include this everywhere. (Note that INCLUDE wasn't standard until Fortran 90, though it did appear in MIL-STD-1753.) Any DATA statements should be confined to a BLOCK DATA subprogram that included the COMMON definitions.
If replacing the COMMON with module variables, any EQUIVALENCE would need to be in the same module where the variables were declared. Maybe that is the issue you ran into?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Steve_Lionel , your prescience is amazing... what you described is exactly what happened. The fix is straightforward, as you noted (and reorganizing the code to get rid of EQUIVALENCE would be even better, of course).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Glad to hear it. Getting rid of EQUIVALENCE may be hard or easy, depending on why it was used in the first place.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page