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

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

MatthewZ
Novice
1,936 Views

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.

Labels (1)
0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
1,919 Views

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.

View solution in original post

8 Replies
mecej4
Honored Contributor III
1,922 Views

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

0 Kudos
MatthewZ
Novice
1,917 Views

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.

0 Kudos
Steve_Lionel
Honored Contributor III
1,920 Views

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
Novice
1,907 Views

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.

0 Kudos
JohnNichols
Valued Contributor III
1,113 Views

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.  

0 Kudos
Steve_Lionel
Honored Contributor III
1,902 Views

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.

0 Kudos
Ron_Green
Moderator
1,844 Views

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


0 Kudos
Devorah_H_Intel
Moderator
1,135 Views

This was fixed in 2021.7 ifort. 

0 Kudos
Reply