Path: utzoo!attcan!uunet!lll-winken!csd4.csd.uwm.edu!bionet!agate!usenet
From: jerry@violet.berkeley.edu ( Jerry Berkman )
Newsgroups: comp.lang.fortran
Subject: Re: How much illegal are these?
Message-ID: <1989Aug20.181847.9199@agate.berkeley.edu>
Date: 20 Aug 89 18:18:47 GMT
References: <116400001@uxa.cso.uiuc.edu>
Reply-To: jerry@violet.berkeley.edu ( Jerry Berkman )
Organization: University of California, Berkeley
Lines: 62

In article <116400001@uxa.cso.uiuc.edu> gsg0384@uxa.cso.uiuc.edu writes:
>
>How much illegal are the following two statements?
>
>      real b, c, a(10,10)
>      data a/100*1./  ! or assign them by two do loops
>
>          b = 0*a(0,2)
>          c = 0*a(1,0)
>
>      print*, b,c
>
>1. Is the first line equivalent to  b = 0*a(10,1) on every machine?  If it is,
>   can't we say it's legal?  Anyway, is the outcome machine-dependent?

This does not necessarily work on all machines, or more correctly, with
all compilers.  For example, on our IBM:

    watfor77 test
    *ERR* SS-04 subscript expression out of range; A(0,2) does not exist
    TraceBack:  Executing in MAIN, statement 4 in file TEST FORTRAN
    Ready(01001); T=0.02/0.05 10:27:06

WATFOR77 gives a fatal error, and never executes the print statement.
I believe there have been descriptor based implementations of Fortran
(Burroughs?) which would also abort on illegal subscripts.

Most Fortran systems don't check subscripts.  However, optimizing compilers
move code around and vectorizing compilers check for recurrences
assuming that array subscripts are legal.  Consider:

	do 100 j=1,100
	    a(1,j+ind1) = sqrt(b(j))+d(j)+e(j)
	    a(2,j+ind2) =     b(j)
100	continue

the compiler may decide to do the second line first in order not to tie
up a register with b.  If these overlap due to illegal subscripts,
the result in general is unpredictable.

>
>2. Does the second line always give c = 0. on every machine?

No, not with WATFOR77.  The location of a(1,0) using the storage
layout of the standard would be equivalent to a1(-9) in an
equivalent linear array a1.  There is no guarantee this storage
location is available for this user; i.e. there could be a
segmentation violation.  Also, this is a bad test as many
compilers will see it is "0*" and not even bother compiling code
for the array reference.

>
>This kind of cases always occur when one wants to vectorize do loops.

I've vectorized a lot of DO loops and rarely encountered this problem.
This is very bad programming practice; it leads to unreadable and
unmaintainable code.

>
>Hugh      song@ardent1.ceg.uiuc.edu or gsg0384@uxa.cso.uiuc.edu

Jerry Berkman, U.C. Berkeley, jerry@violet.berkeley.edu