- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FortranFan
you are absolutely right, my code looks like your example below are some more details
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The newer compiler caught an error the old one did not. The second EQUIVALENCE line is unnecessary and violates the standard's rules.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
![](/skins/images/7FC17B7B85029576C25F1E43CE255B51/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page