Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

How to ignore an error diagnose

Thierry_L_
Beginner
461 Views

Dear all,

I have a code which used to compile (and run) for years using ifort compiler.

With version 2018.104 now I obtain 

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


I tried to disable it or turn it into a warning but still it refuses to compile. Is there any solution as rewriting the code is not option.

Thanks.

  Thierry 

 

 

 
 

 

 

0 Kudos
16 Replies
Lorri_M_Intel
Employee
461 Views

What you show is a warning, so is there a different message that is an error?

If you can show more code, we may be able to help you.   My crystal ball is out for repairs, so I can't really make a guess using just this info.

                         --Lorri

jimdempseyatthecove
Black Belt
461 Views

Show both the common and the declaration as well as any attributes and/or bind(c), and anything else that is of important.

Edit: and if you are using the Fortran PreProcessor, show any #define that aid the reader in knowing what the compiler knows.

Jim Dempsey

FortranFan
Honored Contributor II
461 Views

@Thierry L.,

As Lorri implied, you need to provide a complete reproducer.  It should be trivial effort to put one together along with your selected compiler options.  You probably have code that might be equivalent (pun intended!) to the following:

      SUBROUTINE S()
         INTEGER I
         REAL R
         EQUIVALENCE (I, R)
         COMMON / C / I, R
      END SUBROUTINE

And this will be ordinarily be raised as an error, not a warning. 

xxx>ifort /c m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

m.f90(4): error #7615: Multiple objects from the same EQUIVALENCE set may not ap
pear in a COMMON block.   
         EQUIVALENCE (I, R)
-------------------------^
compilation aborted for m.f90 (code 1)

xxx>

Note it is an error per the Fortran standard.  But you are likely using compiler option(s) to reduce the above to a warning and now you want to suppress it.  Intel Fortran team and other readers can help you if you provide more details.

jimdempseyatthecove
Black Belt
461 Views

FF (or Steve),

Can you explain why #4 is invalid, and then show the proper way to have common block /C/ with I and R.

Jim Dempsey

Thierry_L_
Beginner
461 Views

 

FortranFan

you are absolutely right, my code looks like your example below are some more details

muint2.F(213): error #7615: Multiple objects from the same EQUIVALENCE set may not appear in a COMMON block.   [IQ]
      equivalence (q(1),iq(1))
------------------------^
compilation aborted for muint2.F (code 1)
 
with q and iq appearing in a included common
 
      double precision q
      common /big/ q(2)
      integer iq(2)
      equivalence (q(1),iq(1))
 
The point is, I just compiled it again using ifort from composer_xe_2013.3.163 and got no error message.
 
Regards
 
   Thierry
FortranFan
Honored Contributor II
461 Views

jimdempseyatthecove wrote:

.. Can you explain why #4 is invalid, and then show the proper way to have common block /C/ with I and R. ..

Jim,

Since COMMON provides blocks of physical storage already based on storage association, it really doesn't make sense for EQUIVALENCE to again specify the storage unit more than once in a storage sequence.  So there is no "proper way to have common block /C/ with I and R" - it's needless, one only needs to include one of the two in the COMMON.

FortranFan
Honored Contributor II
461 Views

Thierry L. wrote:

.. 

      double precision q

      common /big/ q(2)

      integer iq(2)

      equivalence (q(1),iq(1))

..

@Thierry L.,

But your above posted snippet will compile with no error message with both current Intel Fortran compiler as well as the 2013 version, 

Steve_Lionel
Black Belt Retired Employee
461 Views

To expand on FortranFan's post...

Here's the text from the Fortran 2008 standard:

5.7.2.2 Common block storage sequence
1 For each common block in a scoping unit, a common block storage sequence is formed as follows:
  (1) A storage sequence is formed consisting of the sequence of storage units in the storage sequences
  (16.5.3.2) of all data objects in the common block object lists for the common block. The order of
  the storage sequences is the same as the order of the appearance of the common block object lists in
  the scoping unit.
  (2) The storage sequence formed in (1) is extended to include all storage units of any storage sequence
  associated with it by equivalence association. The sequence shall be extended only by adding storage
  units beyond the last storage unit. Data objects associated with an entity in a common block are
  considered to be in that common block.

So in post #4 we have:

EQUIVALENCE (I,R)

which says that the first storage unit of I and R are the same. Then we have:

COMMON /C/ I, R

which says that I and R are distinct storage sequences in the order specified. This is a conflict.

As noted, just putting one variable from an equivalence group into COMMON implicitly puts all variables from that group into the same COMMON. You don't need to and in fact are not allowed to name more than one variable in an equivalence group in a given COMMON.

jimdempseyatthecove
Black Belt
461 Views

Thanks this is clear now :

COMMON /C/ I,J,K ! integer 4's
EQUIVILENCE (I,R) ! when R is REAL(4) "union" with I

However consider:
COMMON /C/ I,J,K ! integer 4's
EQUIVILENCE (I,R) ! when R is REAL(8)

My perception is:
EQUIVILENCE (I,R) ! when R is REAL(8) "union" with I:J (J can get clobbered)
However, your wording indicated that the storage area for I/R, R becomes 8, making J,K  shuffle over 4 bytes (as well as extending C by 4 bytes, if not extended elsewhere)

Which is it?

Jim Dempsey

 

Thierry_L_
Beginner
461 Views
Many thanks for all your comments. Actually, it seems that the problem was that the 'equivalence' statement appeared twice: once in the included file with the common and once in the main code. That mistake wasn't detected by previous versions of the compiler or at least didn't give an error message. Removing the 'equivalence' in the main code solves the problem. Thierry
Steve_Lionel
Black Belt Retired Employee
461 Views

jimdempseyatthecove wrote:

However consider:
COMMON /C/ I,J,K ! integer 4's
EQUIVILENCE (I,R) ! when R is REAL(8)

My perception is:
EQUIVILENCE (I,R) ! when R is REAL(8) "union" with I:J (J can get clobbered)
However, your wording indicated that the storage area for I/R, R becomes 8, making J,K  shuffle over 4 bytes (as well as extending C by 4 bytes, if not extended elsewhere)

No shuffling. Your perception is correct. But consider if instead one had:

EQUIVALENCE (K,R)

in this case, the COMMON would be extended by four bytes to get the high-order part of R.

Jong-Gwan_D_Intel
461 Views

I've got the same error for the below test code which compiles and works okay till 2017 update 5.

subroutine t()
        integer, dimension(3) :: i
        integer, dimension(2) :: j
        integer :: k

        equivalence (i(1),j(1))
        equivalence (i(2),j(2))
        equivalence (i(3),k)

        common /data/ i
end subroutine

Commenting out 'equivalence (i(2),j(2))' line will be compiled okay with 2018 compiler. And does this commenting out also work well as expected?

Steve_Lionel
Black Belt Retired Employee
461 Views

The newer compiler caught an error the old one did not. The second EQUIVALENCE line is unnecessary and violates the standard's rules.

Ronald_G_2
Beginner
461 Views

I just ran into this same message building HDF5 1.10.1.  If I have time I'll file a bug to the HDF5 developers.

I dropped back to 2017 compiler to get a build.

dogunter
Beginner
461 Views

I'm now hitting this trying to compile HDF5 with Intel 18.0.1. RonaldG, did you ever hear back from the HDF5 folks or find another solution?

 

 

IanH
Black Belt
461 Views
Reply