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

[Malcolm Cohen]

Dick Hendrickson wrote:
> Subject: What effect does EQUIVALENCE have on variable attributes?
>   
Not a lot.
> 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?
>   
No.
> 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.
>   
Absolutely.

The standard says exactly what conditions cause entities to have 
attributes, end of story.  If the standard says it, it does.  If the 
standard does not say it, it does not.
> But, what about ASYNCHRONOUS, VOLATILE, and SAVE?
>
> 1)  Given
>           ASYNCHRONOUS  ::  X
>           EQUIVALENCE(X,Y)
>
> does Y have the ASYNCHRONOUS attribute?
Not unless the standard says it does.

This is exactly the same situation as

   REAL X
   END

Does X have the ASYNCHRONOUS attribute?  Obviously not.  In both cases.  
(According to the standard as currently written; this seems consistent 
and unambiguous, whether it is what was intended is another matter ...)
>   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?
>   
It's the other way around.  Is the user allowed to asynchronously update Y?

Since Y is not ASYNCHRONOUS, no.  That effectively means the user is not 
allowed to update X either in this example, but the standard doesn't 
require the user program to be sensible.

One can construct a more plausible example with

   REAL,ASYNCHRONOUS :: x(100)
   REAL y
   EQUIVALENCE(x(13),y)

Then all of X is allowed to be updated asynchronously except for X(13).

I don't see any problem here.
> 2)  Same question for VOLATILE
>   
Same answer.
>            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).
>   
If A is affected by means outside the program, then so is B which is not 
volatile and so the program is not standard-conforming.
> 3)  Same question for SAVE
>   
Ah, well this one is more interesting.  The standard might well not be 
consistent here.
>           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.
>   
Only R has the SAVE attribute.
> 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?
>   
It would seem not, but the more interesting part arises when you 
consider default initialization.  Given

SUBROUTINE s1
   TYPE T
     REAL :: C = 3.0
   END TYPE
   TYPE(t) x,y
   SAVE x
   EQUIVALENCE(x,y)
   x = t(1.0)
   RETURN
ENTRY s2
   PRINT *,y  ! Does this print 1.0 or 3.0?
END

It looks like we need to say that if any object in an <equivalence-set> 
has the SAVE attribute, all objects in the set have the attribute.  At 
least, I couldn't find anything that resolved or ruled out this apparent 
contradiction (re the definition status and value of X and Y; I didn't 
look for very long though.)  Maybe someone should submit an interp request.

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.