Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone?
Summary: Actually both interpreation work on this case.
Message-ID: <1901@epsilon.oakhill.UUCP>
Date: 15 Mar 89 00:33:57 GMT
References: <458@orange19.qtp.ufl.edu> <28506@sgi.SGI.COM>
Organization: Motorola Inc. Austin, Tx
Lines: 142

I hate long articles but since I did alot of thought on this subject
earlier I though I'd bore you with the benefit of my cognition.  The
test case I posted earlier had three acts that combine to cause
ambiguity.  These are:

  1) Do loops ending on the same statement
  2) The end statement being executable.
  3) A jump in the external Do loop to the terminating statement.

All three of these are needed to result in the ambiguity.  In the test
case posted:

> <<       PROGRAM LOOP
> <<       IGO = 1
> <<       DO 501 I = 1, 10
> <<          WRITE (6,*) 'OUTER LOOP, I =',I
> <<          IF (IGO .NE. 0) GOTO 501
> <<          DO 501 J = 1, 5
> <<             WRITE (6,*) 'INNER LOOP, J=',J
> <<  501     CONTINUE
> <<          STOP
> <<          END

this is not the cause of the problem.  The true cause of the problem
is that the compiler was tring to resolve the chance of ambiguity,
and generated the bad code.  This is the same as the compilers that
generated 92 in the test case I posted.  Let's look at my test case again.

      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

I claim there are three responses.

 1) Error out.
 2) Execute K = K + 1 as part of the inner loop (Thus the external goto 
    jumps past this statement).  (result 80)
 3) Execute K = K + 1 as part of both loops.  (result 82)

The biggest problem is the the interpretation of what this last statement
means.  The three different interpretation result in the three above results.
The hardest one to implement is the third.  To see why let's look at the
block code generated (For the explaination of the bug that is in the
first code and produced 92 in my case, it is at the end)

For case 2:

   k = 0
   iter1 = 10
   i = 1
LABEL1:
   jump i == 1 or i == 5 LABEL4
   iter2 = 10
   j = 1
LABEL2:
   jump j == 3 LABEL3
LABEL3:
   k = k + 1
   iter2 = iter2 - 1
   j = j + 1
   jump iter2 > 0 LABEL2
LABEL4:
   iter1 = iter1 - 1
   i = i + 1
   jump iter1 > 0 LABEL1
   call print(k)
   end

For case 3:

   k = 0
   iter1 = 10
   i = 1
LABEL1:
   jump i == 1 or i == 5 LABEL4
   iter2 = 10
   j = 1
LABEL2:
   jump j == 3 LABEL3
LABEL3:
   k = k + 1
   iter2 = iter2 - 1
   j = j + 1
   jump iter2 > 0 LABEL2
   jump LABEL5:
LABEL4:
   k = k + 1
LABEL5:
   iter1 = iter1 - 1
   i = i + 1
   jump iter1 > 0 LABEL1
   call print(k)
   end

Note the differences between the two.  The second case must generate 
k = k + 1 twice.  Also it MUST generate the jump to LABEL5:.  It is
the failure to generate this jump that cause the error in the code
(caused the generation of 92 in my case).  The code for the second
case is both slower and harder to generate. 

There is a big temptation to try to tamper with the fragile structure
to speed it up that results in the generation error.  The inifinite
loop errors results from this temptation.  If you allow block jumps
you must use a iteration variable and guard against the iteration
count falling below zero (use <= as opposed ==).  The reason is that
the loop variable can be used outside it's loop.  And if a jump is
made into a do loop, the iteration will be decremented again, a less
than zero will allow the fall through (you can optimize out the
iteration variable only once you determine there is no external jump
into the loop).

Personally I really don't care which interpretation is chosen.  My
theory is that once one or the other is accepted, that the compiler
writer should try to cover the hardship for the user.  The complaints
I've heard about FORTRAN that the lexical analyser is to hard to 
write fall in this catagory.  If the user perfers to start his programs
in column 7, that's his preference.  The compiler writer should do
his work without complaining.

The problem I see is there is a repeated desire to do this code.
Unfortunately the standard refuses to see the upcry, and claims the
whole situation is illegal.  Compiler writers support this extension
(often without warning) to support the market cry, unfortunately
the ambiguity and bad generated code is the unhappy result.

                   enough from this mooncalf - Steven
----------------------------------------------------------------------------
To flame someone for bad spelling or grammer is a discouragement to net
discussion in a timely fashion.
----------------------------------------------------------------------------
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)
----------------------------------------------------------------------------