Re: RFA: Revamp fortran array types

[Tobias Burnus <burnus at net-b dot de>]

On 08/19/2009 03:01 PM, Michael Matz wrote:
> On Wed, 19 Aug 2009, Toon Moene wrote:
>
>   
>>> It would be really good if somebody could check with the fortran gods 
>>> if this is or isn't the case.
>>>       
Unless someone quotes otherwise from the standard, I am pretty sure that
(a) the program is valid and (b) that I quoted and understood the
relevant part from the standard correctly.

>> Two names must not refer to the same or overlapping storage unless you, 
>> the programmer, indicate that they do (by either using EQUIVALENCE or 
>> designating the storage with the TARGET attribute).
>>     

I agree about TARGET, but I do not fully agree about EQUIVALENCE.
Equivalenced variables share the same memory location, but only under
certain restrictions on may make use of it. (Though the expectations of
the users is probably more than what the standard guarantees.)

integer :: i, j
real :: r
equivalence(i,r)
i = 5   ! OK
r = 42.0 ! OK
j = i  ! Invalid according to the standard: value of "i" is undefined

I think most compilers will assign the bitpattern of "r"/42.0 to "j" (as
"i", "j" and "r" have the same storage size) but anything goes. I think
nearly all users expect that the bitpattern is preserved, but the
standard does not enforce this.

Do we handle this properly? I mean the effective aliasing - at least for
the real/complex case? (I would guess so, but I have not checked.)

Another item would be variables in COMMON blocks; I have not fully
studied the standard, but it seems as if the following could be valid -
and might not be handled correctly in terms of "restrict". (Though a
simple test indicates that it is seemingly properly handled.)

module m
   integer :: i
   COMMON /ONE/ i
end module m

use m
  integer :: j
  COMMON /ONE/ j
  j = 5
  i = 1
  print *, j
end module m


For EQUIVALENCE/COMMON see the following excerpt where the special cases
are:
   real(kind) <-> real(kind), real<->complex and complex<->complex
(I do not understand why integer <-> integer is missing.)

"16.5.6 Events that cause variables to become undefined" (from F2003)
"Variables become undefined as follows:
  (1) When a variable of a given type becomes defined, all associated
variables of different type become undefined. However, when a variable
of type default real is partially associated with a variable of type
default complex, the complex variable does not become undefined when the
real variable becomes defined and the real variable does not become
undefined when the complex variable becomes defined. When a variable of
type default complex is partially associated with another variable of
type default complex, definition of one does not cause the other to
become undefined."

Tobias