Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!iuvax!pur-ee!j.cc.purdue.edu!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags
From: ags@s.cc.purdue.edu (Dave Seaman)
Newsgroups: comp.lang.fortran
Subject: Re: Assigned GOTO
Message-ID: <3350@s.cc.purdue.edu>
Date: 7 Jul 88 14:54:27 GMT
References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <12215@mimsy.UUCP> <2261@sugar.UUCP>
Reply-To: ags@s.cc.purdue.edu.UUCP (Dave Seaman)
Organization: Purdue University
Lines: 28

In article <2261@sugar.UUCP> ssd@sugar.UUCP (Scott Denham) writes:
>Such use might look something like 
   
>          ASSIGN 1400 TO R1
>          GOTO 10020
>     1400 CONTINUE 
>          .......
>    10200 FOO = FOO ** 2
>          .......
>          GOTO R1 (1400,1500,1600,1700) 
 
> Unfortunately, IBM's compiler does no checking whatsoever of the possible
> return values - at one time they didn't even have to be valid labels!!
> This can lead to some rather misleading documention. Are other compilers
> as loose with the defintions ???  

The fact that a compiler does not check the return values does not
necessarily mean that it is safe to put in anything you like.  An
optimizing compiler may assume (without bothering to check) that your list
of return values is accurate and use that assumption to generate more
efficient code.  Naturally, such code is likely to break if the
destination of the GOTO is not in the label list.  

I have actually seen this happen with CDC's old FTN compiler.  The program
worked with optimization turned off, but bombed with optimization on.

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