error #7615: Multiple objects from the same EQUIVALENCE set may not appear in a COMMON block.

[MatthewZ]

We are in the process of updating our FORTRAN compiler from 2013 14.0.0100.12 to the oneAPI Toolkit FORTRAN Classic compiler version 2021.2.0.243

With one project that compiles and runs without problems in the older package, one file will not compile in the 2021.2.0.243 FORTRAN classic compiler giving the following error on that file:

error #7615: Multiple objects from the same EQUIVALENCE set may not appear in a COMMON block. [BMAX2]

I have attached the file that is showing this error to this post.

The error points to the following equivalence set:

equivalence &
(blary(64),tcir), (blary(118),bmax2)

I assume that the member that error message is referring to is bmax2. I have looked for common blocks that contain bmax2 in the file and in other files in the project, however, there are none. There is, however, one common block that contains blary in the file. I did find another equivalence set that also contains bmax2.

Since I am unable to find a common block that contains bmax2, what is this error message telling me and what is the suggested fix for this type of situation? I did read that equivalence is obsolete which seems rational since it is meant to share memory among different variables and this seems unnecessary with the fact that modern computers usually contain copious amounts of memory.

I get that there are differences in the compiler versions and that something may have changed between the two versions, however, it seems rather strange that this file compiled and ran properly with the older version of the compiler, yet not in the newest version.

Thanks in advance.

[mecej4]

You need to supply, in addition, the sources of all the modules USEd in your a10101.f90.

[MatthewZ]

As I mentioned, there are no common blocks in the rest of the project that contain bmax2, however, I am attaching the modules you requested.

EDIT: Delete the attachments as Steve's reply solved the problem.

[Steve_Lionel · Accepted solution]

It is normal for newer compiler versions to detect errors that older versions did not.

The error message was really due to your specifying the equivalence between blary(118) and bmax2 twice. My guess is that the compiler is trying to apply this rule from the standard: "An EQUIVALENCE statement shall not specify that the same storage unit is to occur more than once in a storage sequence.", but is getting confused. I ran your source (once I removed the dependencies on modules not supplied) through the NAG compiler and it did not complain about this.

You have identified a bug in ifort, but the easy solution for you is to remove the redundant equivalence group.

[MatthewZ]

Thanks for pointing that out. I will keep in mind that as we move forward with our conversion to the new compiler that there might be other instances like this if the error is not consistent with the code.

Thanks for letting us know this is a bug. The project is now compiling with the second equivalence commented out, and it produces results that are close enough to the old version to be acceptable to us.

I've been used to C# for the past 20 or so years, having done many years of unmanged c++ before that. With c#, a "multiply defined" error like that would have been caught even before attempting the compile. I am perhaps too used to C#'s hand-holding.

[JohnNichols]

C# does hold your hand, but it is to the stupid stage now where stuff on VS2019 with net 5 will not build with VS2022 with net 6.  At least with Fortran you can always go back. 

C# is just a variant of Fortran but slow.  

[Steve_Lionel]

Fortran doesn't allow multiple declarations, but it doesn't have a rule about creating a duplicate storage sequence with EQUIVALENCE. It's harmless so it doesn't seem useful to add that to the language, especially as EQUIVALENCE is obsolescent. 

You get this same error message if you DO try to create inconsistent equivalence groups, and the message is just confusingly wrong.

[Ron_Green]

bug ID is CMPLRIL0-33864

I just wrote up a simple repro

subroutine repro

implicit none

real :: blary(200), bmax2

common /aryt2/ blary

equivalence (blary(118),bmax2)

integer :: foo

equivalence (blary(118),bmax2)

print*, ""

end subroutine repro

[Devorah_H_Intel]

This was fixed in 2021.7 ifort.