topic Re: Bug with EQUIVALENCE ? in Intel® Fortran Compiler

Bug with EQUIVALENCE ?

OP1 — Mon, 05 Dec 2022 19:33:57 GMT

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

Re: Bug with EQUIVALENCE ?

Steve_Lionel — Mon, 05 Dec 2022 20:00:49 GMT

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]

Re: Bug with EQUIVALENCE ?

OP1 — Mon, 05 Dec 2022 20:15:23 GMT

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.

Re: Bug with EQUIVALENCE ?

Steve_Lionel — Mon, 05 Dec 2022 20:33:44 GMT

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?

Re: Bug with EQUIVALENCE ?

OP1 — Mon, 05 Dec 2022 21:55:21 GMT

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

Re: Bug with EQUIVALENCE ?

Steve_Lionel — Mon, 05 Dec 2022 22:22:35 GMT

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