Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!ags
From: ags@mentor.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN array aliasing -- potential problems?
Message-ID: <3525@mentor.cc.purdue.edu>
Date: 31 Jul 89 20:00:03 GMT
References: <8907311910.AA15243@robalo.nyu.edu>
Reply-To: ags@mentor.cc.purdue.edu (Dave Seaman)
Organization: Purdue University
Lines: 47

In article <8907311910.AA15243@robalo.nyu.edu> mckenney@ROBALO.NYU.EDU (Alan McKenney) writes:

  [Description of subroutine call involving aliased arrays]

>    The call to SUB1 violates the FORTRAN standard, since A, B, and C
>actually refer to the same array, and are modified.  In most
>implementations that I know of, A, B, and C are effectively
>EQUIVALENCEd to WORK, so it is as if I had used A instead of B and C.
>The code I have described works on such a system.
>
>    The FORTRAN on the DECsystem-10 used to copy scalar arguments
>into local storage on entry and copy them back on exit; I can conceive
>of systems which would do that for arrays as well, so WORK would be set
>to either A, B, or C (it being undefined which, but it would be exactly
>one of them.)  My code would also work on such a system.
>
>    My question then: are there FORTRAN implementations, either
>existing or which one could make an argument for using, under which
>such code would break?

Several routines in the standard eigensystem package known as EISPACK make
similar assumptions about associated arrays, and some of the routines fail on
a CDC Cyber 205 under FTN200 (and presumably also on ETA machines running
ftn77, which is derived from FTN200).

The problem is that some of the routines contain associated output arrays
called E and E2, where the documentation says that if you don't care about E2,
then you can use the same array for both.  The code uses DO loops of the form,

	DO 200 I=1,N
	  E2(I) = ...something...
	  E(I)  = ...something else...
    200 CONTINUE

The code explicitly depends on the E values being stored after the E2 values.
The trouble is that an optimizing compiler has every right to assume that E
and E2 are not associated, and therefore that the values may be stored into E
and E2 in whichever order is convenient for maximum efficiency.

Getting back to the question that was asked, it appears to be true in this case
that the resulting values are either all E2 values or all E values, not a
mixture of the two.  Even that may change if the program contains conditional
stores, or DO loops with nonunit strides.

-- 
Dave Seaman	  					
ags@seaman.cc.purdue.edu