Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: Re: Dubious Fortran Construct
Summary: OPPs, I was wrong, solutions and a question.
Keywords: DO loops; transfer of control
Message-ID: <1740@devsys.oakhill.UUCP>
Date: 13 Dec 88 18:20:37 GMT
References: <22994@sgi.SGI.COM> <3672@s.cc.purdue.edu>
Organization: Motorola Inc. Austin, Tx
Lines: 95

<1734@devsys.oakhill.UUCP>

Before reading this letter, be aware the meat of this letter is at the end.

In article <1734@devsys.oakhill.UUCP>, steve@oakhill.UUCP (steve) writes:
>   I am not sure, but I think you are wrong.  I do not have my copy
> of my standard here, so I can not reference it, but I think the code
> is correct.  I think the standard defines the CONTINUE to be in the
>   .
>   .
>   .

I'm sorry.  I made a mistake.  I looked this one up in the standard over
the weekend, and unfortunately this area is hopelessly ambiguous.  After
some reflection (and reading yesterday post from Bill Leonard, Member X3J3)
I think we should discuss whether this construct should be illegal.  As I 
stated in the last post, if this practice isn't STANDARD it at least in
standard useage.   I know several compilers that support this (including
ones I've written (this section in fact)).

In the most often occuring case the implemetation is simple.  Lets take
the case given.

      DO 10 I = 1,N
        ...
        IF (A(I) .EQ. 0) GOTO 10
        ...
        DO 10 J = 1,N
          ...
          IF (A(J) .EQ. 0) GOTO 10
          ...
   10 CONTINUE

(WARNING - the next paragraph is a compiler's eye-view.  Skip it if you
want to try to follow my text without it (it is posible).  If you want a
more detailed description, write me, and I'll email it back).

When the external DO loop is encountered, the compiler will make three new
blocks for code.  The first block will contain the code for the external
DO loop.  The second block will contain the code for incrementing the
DO loop.  And the final block will be for a jump over this loop in the
case of non-iteration.  At this point the jump to 10 will generate a jump
to the second created block (the iteration block to the DO loop).  The
internal DO loop then generates similar blocks to the external loop.
At this point the GOTO 10 will generate a jump to the second block of
the internal loop.  (I know this is a bad description, but I can do it
in 10 lines or 154 :-) ).

  Thus internal jumping to 10 does the right thing.  Unfortunately this
is a special case.  Line 10 is a CONTINUE statement.  If Line 10
executed some code, what should we do.  Does that code get executed 
if we take the first GOTO?.

I see four ways this could be done.

1) Not allow this jump.  This is what the committee is proposing.  It is
   a nice simple copout that solves the problems all together.  Unfortunaely
   it ignores the fact that a lot of programers and code use this.

2) Allow this in the case where the final line of a DO loop is a CONTINUE
   and no other time.  This will be acceptable to current coding practice
   and avoids ambiguity.

3) Execute the code as if it was part of the internal loop.  Don't 
   execute it if you took the first GOTO.  This is fine, but slightly
   amibigious.  It treats the case as if there was an invisible CONTINUE
   at the end of the loop.

4) Execute the code as if it was part of every loop.  This is the
   messy case (but not that hard).  It means you must generate this
   statement once for every loop, and then put appropriate jump arounds
   of the latter copies to prevent multiple execution.

I personally vote for 2 or 3.  Since there are many compilers that compile
code like above, I'd like to do a survey.  Please compile the below code
on your computer, and e-mail me back the results (with computer, operating
system, etc.).  I'll post the results.

      K = 0
      DO 10 I = 1,10
        IF (I.EQ.1.OR.I.EQ.5) GOTO 10
        DO 10 J = 1,10
          IF (J.EQ.3) GOTO 10
   10 K = K + 1
      PRINT *,K
      END

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
These opinions aren't necessarily Motorola's or Remora's - but I'd like to
think we share some common views.
----------------------------------------------------------------------------
Steven R Weintraub                        cs.utexas.edu!oakhill!devsys!steve
Motorola Inc.  Austin, Texas 
(512) 440-3023 (office) (512) 453-6953 (home)
----------------------------------------------------------------------------