Path: utzoo!attcan!uunet!husc6!cs.utexas.edu!oakhill!steve
From: steve@oakhill.UUCP (steve)
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone?
Summary: The strike of the second whammy
Message-ID: <1917@devsys.oakhill.UUCP>
Date: 19 Mar 89 00:21:54 GMT
References: <1913@devsys.oakhill.UUCP> <10623@lanl.gov>
Organization: Motorola Inc. Austin, Tx
Lines: 82

In article <10623@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <1913@devsys.oakhill.UUCP>, by steve@oakhill.UUCP (steve):
> > [...]
> > Unfortunately you can't save the unwashed masses from themselves.
> > Not only can you not prevent them from doing this.  If you forbid
> > it, they cry and want it.  If you want to sell compilers, this is
> > something that must be supported.
> 
>       do 10 i=1,10
>          print *,i
>          if (i.gt.5) goto 10
>          do 10 j=1,5
>             print *,j
>  10   continue
> 
> This program infinite loops on the Cray with CFT 1.14.  If this is
> the behaviour that "must be supported" to sell compilers, I don't
> want any part of it.  I consider this to be an _ERROR_ in the 
> compiler and I'm reporting it to Cray as such.  To be fair, the CFT
> compiler does issue a warning that the branch is illegal.

This is the second whammy I talked about happening.  The compiler
writer decided that to generate faster code 99% of the time was
more important that creating correct code all of the time.  I
disagree with this decision completely.  At least when the compiler
generates an infinite loop you know you have a compiler problem.
When it generates a bad result, you are in bad shape.  If you realize
it, than you tear your hair out trying to find your error.  There
is no justifing creating bad code.  Unfortunately many compilers
writers forget that to support something extra means supporting
something extra correctly.

> If a compiler wants to allow the above program it should at least
> compile it to something useful.  The only "meaningful" interpretation
> of the above I can think of is equivalent to the following:
> 
>       do 10a i=1,10
>          print *,i
>          if (i.gt.5) goto 10a
>          do 10 j=1,5
>             print *,j
>  10      continue
>  10a  continue
> 
> If a compiler doesn't issue a FATAL message, it should give the above
> interpretation - nothing else is acceptable.  (Note, I used '10a' as
> the label in the above example to make it clear that it is a compiler
> generated label.)

Going back to my code:

      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

I assume this puts you in the camp that when i = 1 or i = 5 that
k is not incremented.  There is a large segment of coders that think
it should be.  This is the big arguement on ambiguity that started
this arguement.  Personally I'm in your camp.  If the compiler supports
this feature, it should do it right, put out an warning on non-standard
code, and assume the jump in the external DO loop ment to skip this 
statement (Does the next external iteration).  In a perfect world
every compiler will comform perfectly to the standard and not take
short cuts that leave to badly generated code.  But then Elijah
probably would be writing the compilers, and we'd all be out of a 
job :-).

                   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)
----------------------------------------------------------------------------