Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!orca!dsd.es.com!jason
From: jason@dsd.es.com (Jason S. Ehrhart)
Newsgroups: comp.sys.mips
Subject: Re: f77 compiler bug (both MIPS and SGI)
Message-ID: <1991Jun20.213433.24193@dsd.es.com>
Date: 20 Jun 91 21:34:33 GMT
References: <1991Jun19.162129.2870@batcomputer.tn.cornell.edu> <1991Jun17.224729.15190@rice.edu> <1991Jun18.191622.4008@odin.corp.sgi.com> <1991Jun19.133207.24629@cpsc.ucalgary.ca> <1991Jun20.075058.10576@groucho>
Sender: usenet@dsd.es.com
Reply-To: jason@dsd.es.com
Organization: Evans and Sutherland, Salt Lake City, Utah
Lines: 88
Nntp-Posting-Host: 130.187.90.26

Paul Bickerstaff writes:

|> I would like to point out that Mips does market
|> their Fortran compiler as VMS fortran compatible and this is a *big*
|> selling point.  

There is a -vms flag, but the documentation doesn't get into detail 
about what is VMS-Compatible. It states that Mips provides full VMS Fortran
compatibility to the extent possible without the VMS os or VAX data
representation. A little ambiguous there, perhaps it will be made
clearer in a future release of the doc set. Originally, the -vms
flag did very little. It does more now. But obviously not as much as
you'd like.

|> Hence I would like to advocate
|> that Mips adopt the philosophy that their compiler should compile
|> code like that in the above example, perhaps with a warning or perhaps
|> only if some flag is set, but it should be possible to compile the program
|> **and correctly execute it** without rewriting it.  (Could there ever be
|> any problem with jumping to a continue statement at the end of a do loop?)

Mips is aware of this problem.  

To briefly explain, there are two distinct types of statement labels. 
There are Do-Loop terminal statements, and then there are goto 
target statements. When the compiler front-end goes through the code, it 
treats these two types of statements seperately. So, the 
tricky code which handles Do-Loops can get in the way of the 
straight forward goto code, hence the bizarre behavior.

I've looked at the compiler source code for this, it is not pretty. 
It will be a significant rewrite to change this. I am not sure of when
you will see this "fixed" any better than just being flagged.  There is an
an error message put into the 2.20 release which does flag this problem. 
The work-around is already known (seperate statements for doloops 
and goto's), it will not make your code any less portable to make this change.

|> 1) Very similar, if not identical, to the one above. We had a visitor
|> from Germany whose program ran on a Vax, an IBM and a Convex
|> (and probably a Cray) but our Mips spewed garbage. The problem
|> was traced to a construct like
|> 
|> 	do 10 ...
|> 	  ...
|> 	if (...) goto 10
|> 	do 10 ...
|> 	   ...
|>                10 continue

I saw this when I was at Mips, this is the exact same problem. In
fact, I filed the bug report on it.

I do have to make a point about the documentation. On page 6-8 of
Part 2 of the Fortran Language Reference Manual. It is explicitly
stated under Restrictions that:

4. A program must not transfer control into the range of a DO-loop
from outside the DO-loop.

Both of your examples shown here violate this restriction.

|> The use of a single continue as the last statement in overlapping do 
|> loops is apparently allowed -- the Mips fortran manual says so --

You'd have to show me where the documentation sez this. You might
have misunderstood rule number 4 on page 6-8 which states: "The same
statement may serve as the terminal statement in two or more nested
DO-Loops. The problem here is that there is a goto which is
transfering control into the range of a DO-Loop, thus violating
restriction number 4.

|> 2)There is an obscure rule in f77 which requires that data
|> statements come after declarations and before the other
|> program statements.  

This was a problem with revs before 2.20, it is now fixed. Put your
DATA statements where you wish.

|> Please, how about a flag that will let this pass.

We're working on getting it to work correctly without a flag, it
just takes a little time and effort.

-- 
jason ehrhart jason@dsd.es.com  
evans and sutherland
580 arapeen drive           Perspective, use it or lose it.
salt lake city, ut, 84158   (801) 582-5847 x4812