Fortran Wiki
equivalence discussion

This is a discussion page for the deprecated EQUIVALENCE feature in the current standard of Fortran.

NOTE: Although many people claim that EQUIVALENCE and COMMON are deprecated, they are not declared obsolete by the Fortran standards, including Fortran 2008.

(11 june 2009)

While I know that the use of EQUIVALENCE and COMMON blocks has been heavily discouraged for some time, I have yet to find an equivalent (no pun intended) solution for their use with regards to computing fourier transforms in-place. This is a common practice in spectral CFD codes in which the data is either all REAL or all COMPLEX at any given time and is converted back and forth very efficiently using inline FFTs such as the canned FFTW libraries. For these cases, being able to EQUIVALENCE both a real and complex array not only avoids extra storage, but also eliminates unnecessary copies upon exit of the FFT algorithm.

I read several attempts at describing alternative work-arounds for various other uses of the EQUIVALENCE statement, but have yet to find this case mentioned anywhere. I do not like using these deprecated features, but I cannot find another method that even remotely matches the speed and efficiency of the current solution. Does anyone have any insight to this problem? Potentially, a good solution would be to allow both REAL and COMPLEX pointers access to the same target…

Jason Blevins (11 Jun 2009) I haven’t yet had the pleasure of dealing with code that used equivalence, but if I understand, the main issue you’d like to solve is being able to use the same memory for storing two types of data? So, for example, you have an array foo(n,n) that should be able to store either real or complex data? You might have a look at the transfer intrinsic. Unfortunately, I don’t think it would be nearly as efficient as equivalence in this case, as it would require more storage (you could perhaps use dynamic memory allocation to help a bit) and copying data back and forth. Something involving Cray pointers might also make it possible to do without copying or using extra memory. Many compilers support Cray pointers as an extension. Fortran 2003 also has support for C pointers.

Rohou? (31 Jul 2009) I was facing the exact same issue and started a thread on the topic at the ifort forum, which you might want to check out

Neal Van Eck? (21 Oct 2009) I have a similar problem, but I need to equivalence all types of data for a 32000 byte area. I would need 6 such areas otherwise, and have to move data to each of these for every data read. Not feasible at all; can’t do without EQUIVALENCE.

Joe Krahn (17 Jun 2010) EQUIVALENCE is not deprecated even in F2008; it just does not allow storage of any Fortran95 or newer entities such as pointers. IMHO, there is absolutely nothing wrong with EQUIVALENCE if it is not over-used. (See Better support for EQUIVALENCE.) Excessive EQUIVALENCEs are ugly, but so are the work-arounds in cases where EQUIVALENCE is the right thing to do.

This is one of several examples where the Fortran Standards committees have made horrible decisions contributing to the near demise of Fortran. They apparently want to “force” better programming by making some useful features obsolete. That is stupid, because it is always possible to write bad code. Excessive use of globals, GOTOs and equivalences are bad, but are all useful in moderation. To my surprise, F2003 ISO-C-Binding does not even support unions in C data structures!! IMHO, equivalence should be expanded to work with dummy arguments.

The ugly work-around is to either cast Fortran pointers using F2003 C-pointers as a proxy, or use an EXTERNAL procedure interface (i.e. no MODULE or prototype) where sequence-association is still perfectly valid.

Another work-around is to pass the same array twice, where the called routines has declared the array as two different types. However, argument aliasing is also not allowed by the standard, and can result in optimization errors.