Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!deimos!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Dubious Fortran Construct
Message-ID: <50500096@uxe.cso.uiuc.edu>
Date: 16 Dec 88 23:00:00 GMT
References: <22994@sgi.SGI.COM>
Lines: 28
Nf-ID: #R:sgi.SGI.COM:22994:uxe.cso.uiuc.edu:50500096:000:1317
Nf-From: uxe.cso.uiuc.edu!hirchert    Dec 16 17:00:00 1988


On the issue of statement fragments such as
     DO 10 I=1,N
       ...
       IF(...) GO TO 10
       DO 10 J=1,N
       ...
10   statement

Others have adequately pointed out that this fragment is prohibited by the ANSI
standard and that a conforming compiler can do what it wants with such
fragments, including the possibility of rejecting it or giving a "reasonable"
interpretation to it.  While many compilers do choose to try to provide a
"reasonable" interpretation, there are also many that either diagnose this as
an error or generate a transfer to the end of the inner loop, producing an
execution-time logic error.  The problem in choosing a "reasonable"
interpretation comes when "statement" is not a CONTINUE statement.  Things are
a bit irregular if you try to execute the statement (since it is clearly
executed as part of the inner loop), but things would also be a bit irregular
if you GO TO a statement and don't execute it.

Rather than try to define what happens in this case in Fortran 8x, X3J3 has
added the CYCLE statement to perform this function cleanly.  Since CYCLE doesn't
purport to be a transfer to the terminal statement of the loop, its function
can be defined cleanly and without surprises.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications