How to ignore an error diagnose

[Thierry_L_]

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 

[Lorri_M_Intel]

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]

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]

@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]

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_]

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]

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]

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]

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]

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_]

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]

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]

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]

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]

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]

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]

See patch in https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/747951