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

Bug with EQUIVALENCE ?

OP1
New Contributor II
501 Views

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

 

 

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
483 Views

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? 

View solution in original post

5 Replies
Steve_Lionel
Honored Contributor III
487 Views

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]

 

0 Kudos
OP1
New Contributor II
484 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
484 Views

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? 

OP1
New Contributor II
473 Views

@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). 

0 Kudos
Steve_Lionel
Honored Contributor III
472 Views

Glad to hear it. Getting rid of EQUIVALENCE may be hard or easy, depending on why it was used in the first place.

0 Kudos
Reply