(j3.2006) What effect does EQUIVALENCE have on variable attributes?

Dick Hendrickson dick.hendrickson
Fri Mar 6 22:42:44 EST 2009


Subject: What effect does EQUIVALENCE have on variable attributes?
This came up on comp.lang.fortran a couple of weeks ago, and I
don't think there was agreement about what the standard says.

Basically, if one variable in an equivalence set has an attribute
and another one doesn't, does the attribute flow through to the
other variable?

For PROTECTED it's clear.  C584 (F2003) says if one has
the PROTECTED, all must have it.  There's no magic inheritance
of each others attributes.

But, what about ASYNCHRONOUS, VOLATILE, and SAVE?

1)  Given
          ASYNCHRONOUS  ::  X
          EQUIVALENCE(X,Y)

does Y have the ASYNCHRONOUS attribute?  One of the
purposes of ASYNCHRONOUS is to prevent the compiler
from doing code motion optimizations across some I/O
statements, including across subroutine calls if the subroutine
might contain I/O.  Is the compiler allowed to optimize
uses of Y in cases where it isn't allowed to optimize X?

2)  Same question for VOLATILE
           VOLATILE  ::  A
           EQUIVALENCE  (A,B)
     in a sequence like
            C = A
            D = A
the compiler is supposed to do the right thing (and fetch A twice).
How about in
           E = B
           F = B
must there be two fetches?

3)  Same question for SAVE
          SAVE  ::  R
          REAL  ::  S(3)
          EQUIVALENCE (R, I, S(2), T)
Does I have the SAVE attribute?  How about S, or is
only S(2) saved?  How about T.

The question isn't so much implementation details,
R and T are likely to share the same memory location,
but can a standard conforming subroutine reference T
or I in cases where they would otherwise be undefined?
Something like
         subroutine second_call
         SAVE  ::  R
         EQUIVALENCE (R,T)
         print *, T
         entry first_call
         R = 1.0
         T = 25
         end
assuming first_call is called before second_call,
is the print standard conforming?  Does T go out
of scope and become undefined as 16.5.6 (3) (a) says?
Or is it saved by virtue of its association with R?

It's maybe worse for variables of different type.  When
one of them becomes defined, the other becomes
undefined.  I think this allows the compiler to store
the equivalenced variables in different storage locations
(or more likely different registers during their defined
lifetime).  If in the above example T were declared
integer, would it make a difference?  T wouldn't
necessarily be implicitly saved by magically sharing
storage with R.

What happens to the array S?  Someplace it says
that if a compound object has the SAVE attribute,
all of it's components also have the SAVE attribute.
But, I couldn't find the reverse statement.  Does saving
R automatically save all of S?

Dick Hendrickson



More information about the J3 mailing list