bron@bronze.SGI.COM (Bron Campbell Nelson) (12/07/88)
A random question for you all: How does your Fortran compiler handle branches to a DO loop termination statement? In particular, in the following program, statement "10" terminates both DO loops, and is branched to by a statement in the outer DO loop: subroutine foo(a, b, n) real a(n), b(n,n) do 10 i = 1,n if (a(i) .eq. 0) goto 10 do 10 j = 1,n b(i,j) = 1/a(i) 10 continue return end I am aware that the VMS compiler rejects this as illegal since it considers statement 10 to belong to the inner loop, and so the branch would be into an inner block (which is illegal). A couple of variants of the f77 compiler I've dealt with accept the syntax without complaint, but generate bad code (i.e. if a(1) is zero, the loop iteration processing will attempt to examine the value of j, which is uninitialized at that point). The Fortran 77 standard seems a bit ambiguous (to me anyway) as to whether the above is legal. So the question is, do you think the above is legal? Does your compiler think so? -- Bron Campbell Nelson bron@sgi.com The opinions expressed are not necessarily those of the author's employer, are not necessarily those of the author's friends, are not necessarily even those of the author, and are probably not necessary.
ags@s.cc.purdue.edu (Dave Seaman) (12/08/88)
In article <22994@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson) writes: [asks whether this is legal] > > subroutine foo(a, b, n) > real a(n), b(n,n) > do 10 i = 1,n > if (a(i) .eq. 0) goto 10 > do 10 j = 1,n > b(i,j) = 1/a(i) >10 continue > > return > end This is illegal according to the ANSI standard. The range of a DO loop, by definition, consists of all the executable statements following the DO, up to and including the loop termination statement. Therefore the CONTINUE is part of the range of the inner DO. (It also happens to be part of the range of the outer DO, but that's irrelevant). The GOTO is outside the range of the inner DO, but its destination is inside the range. Therefore, it's illegal. -- Dave Seaman ags@j.cc.purdue.edu
bill@hcx2.SSD.HARRIS.COM (12/09/88)
The X3J3 FORTRAN committee has considered this question, and an official interpretation will be published sometime in the near future, I believe. (I can't remember whether we took the final vote or not.) In any case, the concensus seems to be that this is illegal. The terminating statement belongs to the inner loop, so the GOTO is a branch into a DO loop from outside the loop, which is prohibited by the standard. Bill Leonard, Member X3J3 Harris Computer Systems Division 2101 W. Cypress Creek Road Fort Lauderdale, FL 33309 bill@ssd.harris.com or bill%ssd.harris.com@eddie.mit.edu
steve@oakhill.UUCP (steve) (12/09/88)
In article <3672@s.cc.purdue.edu>, ags@s.cc.purdue.edu (Dave Seaman) writes: > In article <22994@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson) writes: > [asks whether this is legal] > > > > subroutine foo(a, b, n) > > real a(n), b(n,n) > > do 10 i = 1,n > > if (a(i) .eq. 0) goto 10 > > do 10 j = 1,n > > b(i,j) = 1/a(i) > >10 continue > > > > return > > end > > This is illegal according to the ANSI standard. The range of a DO loop, by > definition, consists of all the executable statements following the DO, up > to and including the loop termination statement. Therefore the CONTINUE is > part of the range of the inner DO. (It also happens to be part of the > range of the outer DO, but that's irrelevant). > > The GOTO is outside the range of the inner DO, but its destination is > inside the range. Therefore, it's illegal. 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 range of the currently active loop (in the case in question - the outer) when it is the terminal line of multiple DO loops. I know that most compilers will accept this line (then again most compilers will allow as certain amount of jumping into DO loops). I know that the compiler I worked on handled this properly (As I define it :-) ), since I am the one who implemented the code which handles this. Also I use to work for a company that demanded rigid compliance to the FORTRAN standard (for portability), and this was an accepted practice in the style guide (so if it is not truely "STANDARD" code, it is a standard coding practice). I will look up this question at home this weekend, and will post back early next week if noone quotes chapter and verse from the standard (someone who has the standard nearby - please save me the trouble :-) ). enough from this mooncalf - Steven P.S. I am sorry for not replying to the original posting, but we lost several days of mail some days ago, and this posting was probably in it. Anyway I didn't see the post (and I read c.l.f daily). ---------------------------------------------------------------------------- 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) ----------------------------------------------------------------------------
rbr4@uhura.cc.rochester.edu (Roland Roberts) (12/10/88)
In article <22994@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson) writes: [problem (deleted): multiple do loops terminated by single statement statement in outer loop (conditionally) branches to loop termination] >I am aware that the VMS compiler rejects this as illegal since it >considers statement 10 to belong to the inner loop, and so the branch >would be into an inner block (which is illegal). I've used this construct before, so I was rather surprised by this claim. To test it, I've just typed in this code and our VAX/VMS compiler didn't complain in the slightest. -- Roland Roberts BITNET: roberts@uornsrl Nuclear Structure Research Lab INTERNET: rbr4@uhura.cc.rochester.edu 271 East River Road UUCP: rochester!ur-cc!rbr4 Rochester, NY 14267 AT&T: (716) 275-8962
ags@s.cc.purdue.edu (Dave Seaman) (12/10/88)
In article <467@ur-cc.UUCP> rbr4@uhura.cc.rochester.edu (Roland Roberts) writes: >In article <22994@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson) writes: >[problem (deleted): > multiple do loops terminated by single statement > statement in outer loop (conditionally) branches to loop termination] >I've used this construct before, so I was rather surprised by this claim. [i.e. the claim that the construct is illegal] >To test it, I've just typed in this code and our VAX/VMS compiler didn't >complain in the slightest. That does not prove that the code is legal ANSI Fortran. It doesn't even prove that it's legal VAX/VMS Fortran. It only means that you selected a bad test. The correct test to determine whether it is legal ANSI Fortran is to look it up in the ANSI standard, which I already did and posted my findings in a previous message. It is not legal. The correct test to determine whether it is legal VAX/VMS Fortran is to look in the VAX/VMS Fortran manual. Since I don't have one available, I can't answer that one for you except to point out that the fact that "the compiler didn't complain" proves nothing. It may be legal, but only if it specifically says so in the DEC manual. This would then be considered an "extension," which means it is not necessarily portable to other Fortran environments. Compilers are not required to reject all incorrect programs. They are merely required to accept correct programs. Therefore, feeding a dubious Fortran construct to a compiler to see whether it complains is a completely useless exercise. -- Dave Seaman ags@j.cc.purdue.edu
bron@bronze.SGI.COM (Bron Campbell Nelson) (12/10/88)
In article <3677@s.cc.purdue.edu>, ags@s.cc.purdue.edu (Dave Seaman) writes: > In article <467@ur-cc.UUCP> rbr4@uhura.cc.rochester.edu (Roland Roberts) writes: > >In article <22994@sgi.SGI.COM> bron@bronze.SGI.COM (Bron Campbell Nelson) writes: > >[problem (deleted): > > multiple do loops terminated by single statement > > statement in outer loop (conditionally) branches to loop termination] > > >I've used this construct before, so I was rather surprised by this claim. > [i.e. the claim that the construct is illegal] > >To test it, I've just typed in this code and our VAX/VMS compiler didn't > >complain in the slightest. > > The correct test to determine whether it is legal VAX/VMS Fortran is to > look in the VAX/VMS Fortran manual. Since I don't have one available, I > can't answer that one for you except to point out that the fact that "the > compiler didn't complain" proves nothing. It may be legal, but only if it > specifically says so in the DEC manual. This would then be considered an > "extension," which means it is not necessarily portable to other Fortran > environments. > I suppose this last comment is true as far as it goes, but I specifically asked the net whether or not the compiler that you use accepts this construct, and *also* asked whether or not you believe the construct is legal (regardless of whether or not the compiler accepted it). I was a bit surprised by the fact that the VMS compiler accepted it, obviously my memory is faulty. What I *do* know for sure is that the VMS manual specifically declares this construct to be illegal. As for my 2 cents: my compiler accepts it (but generates incorrect code); I think it is illegal and should give a syntax error, or at least a warning. -- Bron Campbell Nelson bron@sgi.com The opinions expressed are not necessarily those of the author's employer, are not necessarily those of the author's friends, are not necessarily even those of the author, and are probably not necessary.
ags@s.cc.purdue.edu (Dave Seaman) (12/13/88)
In article <44400031@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > >The X3J3 FORTRAN committee has considered this question, and an >official interpretation will be published sometime in the near future, I was surprised to see this, because I see nothing ambiguous in the standard. It may be that the committee did not specifically intend to make the construct illegal, but the words they used are quite clear and explicit. Here are the relevant statements: 11.10.1 _Range_of_a_DO-Loop_. The _range_of_a_DO-Loop_ consists of all of the executable statements that appear following the DO statement that specifies the DO-Loop, up to and including the terminal statement of the DO-loop. If a DO statement appears within the range of a DO-loop, the range of the DO-loop specified by that DO statement must be contained entirely within the range of the outer DO-loop. More than one DO-loop may have the same terminal statement. This means that the CONTINUE statement in the example is part of the range of both loops. The GOTO statement in the example is not part of the range of the inner DO-loop. To complete the analysis, only one more fact is needed: 11.10.8 _Transfer_into_the_Range_of_a_DO-Loop_. Transfer of control into the range of a DO-loop from outside the range is not permitted. I did not leave anything out. What you just read is the entirety of what the standard says about transferring into the range of a DO-loop. I don't see how anything could possibly be clearer than that. If the Supreme Court can rule that the First Amendment does not mean what it says, then I suppose there is nothing to stop the X3J3 committee from ruling that the standard does not mean what it says. That is the only way I can make sense of the claim that an "official interpretation" is needed. But if the committee decides that the construct is illegal, then exactly how could they go about rewording the standard to make it any clearer than it is now? -- Dave Seaman ags@j.cc.purdue.edu
trh@ukc.ac.uk (T.R.Hopkins) (12/14/88)
+From eagle.ukc.ac.uk!harrier.ukc.ac.uk!ukc!mcvax!uunet!husc6!mailrus!purdue!i.cc.purdue.edu!h.cc.purdue.edu!s.cc.purdue.edu!ags Tue Dec 13 17:29:53 GMT 1988
+
+In article <22994@sgi.SGI.COM+ bron@bronze.SGI.COM (Bron Campbell Nelson) writes:
+ [asks whether this is legal]
++
++ subroutine foo(a, b, n)
++ real a(n), b(n,n)
++ do 10 i = 1,n
++ if (a(i) .eq. 0) goto 10
++ do 10 j = 1,n
++ b(i,j) = 1/a(i)
++10 continue
++
++ return
++ end
+
+This is illegal according to the ANSI standard. The range of a DO loop, by
+definition, consists of all the executable statements following the DO, up
+to and including the loop termination statement. Therefore the CONTINUE is
+part of the range of the inner DO. (It also happens to be part of the
+range of the outer DO, but that's irrelevant).
+
+The GOTO is outside the range of the inner DO, but its destination is
+inside the range. Therefore, it's illegal.
+
+--
+Dave Seaman
+ags@j.cc.purdue.edu
+
+
ANSI X3.9-1978 page 11-6 line 34 (in the section Range of a DO-loop)
says
"More than one DO-loop may have the same terminal statement"
Section 11.10.2 states
A DO-loop is either active or inactive. Initially inactive, a DO-loop
becomes active only when its DO statement is executed.
Seems to me that when the GOTO is executed the inner loop is inactive.
The effect of the transfer is thus to increment the outer loop counter
(see 11.10.3 and 11.10.4) and restart the outer iteration.
The code is thus legal Fortran 77.
Tim
--
Tim Hopkins, { trh@ukc.ac.uk
Computing Laboratory, trh%ukc@cs.ucl.ac.uk
University of Kent, na.hopkins@score.stanford.edu }
Canterbury CT2 7NF, Kent, UK.steve@oakhill.UUCP (steve) (12/14/88)
<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) ----------------------------------------------------------------------------
hirchert@uxe.cso.uiuc.edu (12/14/88)
Dave Seaman(ags@s.cc.purdue.edu) writes >In article <44400031@hcx2> bill@hcx2.SSD.HARRIS.COM writes: >> >>The X3J3 FORTRAN committee has considered this question, and an >>official interpretation will be published sometime in the near future, >I was surprised to see this, because I see nothing ambiguous in the >standard. The fact that X3J3 considered this question does not mean that X3J3 thinks that there is ambiguity on this issue, but rather that someone asked X3J3 to interpret this question. The requestor argued that since the program is not permitted to branch into the inner loop, the GO TO should be interpreted as branching to somewhere that is was permitted to branch (i.e., the terminal processing for the outer loop). X3J3 said that while this is a permissible extension, there was no justification in the standard for expecting this behavior of all FORTRAN 77 processors. In other words, X3J3 agreed with Dave's interpretation on this question. Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
dik@cwi.nl (Dik T. Winter) (12/14/88)
In article <6172@eagle.ukc.ac.uk> trh@ukc.ac.uk (T.R.Hopkins) writes: > > ++ do 10 i = 1,n > ++ if (a(i) .eq. 0) goto 10 > ++ do 10 j = 1,n > ++ b(i,j) = 1/a(i) > ++10 continue > + > +This is illegal according to the ANSI standard. The range of a DO loop, by > > Section 11.10.2 states > > A DO-loop is either active or inactive. Initially inactive, a DO-loop > becomes active only when its DO statement is executed. > > > Seems to me that when the GOTO is executed the inner loop is inactive. > The effect of the transfer is thus to increment the outer loop counter > (see 11.10.3 and 11.10.4) and restart the outer iteration. Wrong conclusion. As far as I understand this is illegal in Fortran 77 and was in Fortran 66. So the question is, why do many compilers accept it? That is simple: in Fortran 66 it was legal to jump into a loop if you had jumped out of it first: do 10 i = 1, n junk goto 100 10 continue more junk 100 still more junk c if we get here through normal flow, the jump should not be taken. goto 10 was completely legal (it was called an extended do loop range). But you were only allowed to jump to label 10 if the loop was active (as the quote above defines). Many compilers maintained the extended range out of compatibility reasons (I understand Fortran 77 dropped it), and as it is very difficult to check whether the loop is active indeed they allow all kinds of jumps into loops. But if the loop was inactive the loop control variable is undefined and so you get unpredictable behaviour. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
joe@modcomp.UUCP (12/14/88)
Dave Seaman (ags@j.cc.purdue.edu) writes: > In article <44400031@hcx2> bill@hcx2.SSD.HARRIS.COM writes: > > > >The X3J3 FORTRAN committee has considered this question, and an > >official interpretation will be published sometime in the near future, > > I was surprised to see this, because I see nothing ambiguous in the > standard. [...] Here are the relevant statements: > > 11.10.1 _Range_of_a_DO-Loop_. [...] More than one DO-loop may > have the same terminal statement. > > This means that the CONTINUE statement in the example is part of the > range of both loops. The GOTO statement in the example is not part of > the range of the inner DO-loop. Because the CONTINUE statement is being used as the terminating statement of two scopes, an ambiguity exists, since GOTO can only branch into a single scope. Which scope is selected is not stated by the f77 standard. Your implied intepretation of "select that scope which makes sense for the GOTO in question" is a nice feature that Smart Compilers (like mine (:->)) can implement. However, wording to *require* that behavior is not present in the standard. Hence any program that makes use of the ambiguity is nonstandard conforming. -- joe korty uunet!modcomp!joe
chris@mimsy.UUCP (Chris Torek) (12/14/88)
Summary of problem: DO 10 I=A,B IF (cond) GOTO 10 DO 10 J=C,D code 10 CONTINUE more code Background: the problem arises only because the scope of a DO loop is named by a label that may be shared. In other programming languages one escapes by, in essence, forcing programmers to write the inner loop using a different label. Often the label is omitted altogether: do i in [a..b] if cond then do j in [c..d] code od fi od Claim: There is a simple and consistent way to view this problem that makes the `goto' illegal. Approach: since `the range of a DO loop includes the final statement', one should view the code as having an invisible loop delimiter that appears just *after* the labelled statement. Thus the example transforms to: DO I=A,B IF (cond) GOTO 10 DO J=C,D code 10 CONTINUE end do J end do I more code That is, because the DO J loop used label 10 as its final statement, its end appears just *after* the continue statement. The `IF' therefore jumps into its loop. Note that this interpretation of DO-loops gives consistently correct compilations of all other legal constructs. It also seems to me `intuitively proper'. One cannot end the loop *before* the labelled statement (since it must be executed if it in fact does something), and it seems nonsensical to say that the loop ends somehow `inside' the labelled statement, therefore it must end just after---`between the lines', as it were. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
pack@acdpyr.ucar.edu (Dan Packman) (12/15/88)
I ran the following horrible 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
PRINT *,K
END
Results were:
System K
========================================
Pyramid OSX4.0 80
SUN OS 4.0 92
VAX/VMS 4.7 92
CRAY COS1.15 [Warning notice from compiler, infinite loop generated]
I think this particular case (with the numbered line not being a continuation)
should be flagged illegal. "To every do loop, a continue" (or end do)
Dan Packman NCAR INTERNET: pack@acdpyr.UCAR.EDU
(303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET
Boulder, CO 80307 DECNET SPAN: 9.367::PACKags@s.cc.purdue.edu (Dave Seaman) (12/15/88)
In article <11800009@modcomp> joe@modcomp.UUCP writes: [ You all know what the code example looks like by now ] >Because the CONTINUE statement is being used as the terminating statement of >two scopes, an ambiguity exists, since GOTO can only branch into a single ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >scope. Which scope is selected is not stated by the f77 standard. ^^^^^ A GOTO cannot branch INTO any scope whatsoever. See paragraph 11.10.8 of the standard. The important word here is INTO, meaning "from the outside to the inside". A GOTO can branch WITHIN as many scopes as it pleases, but it cannot enter a scope except through the top. There is no ambiguity. >Your >implied intepretation of "select that scope which makes sense for the GOTO >in question" is a nice feature that Smart Compilers (like mine (:->)) can >implement. I don't know who you are referring to here. You quoted my argument that the construct is illegal, so I take it you are addressing me. But I have never attempted to "interpret" that which is not allowed by the standard in the first place. I do not object to extensions, as long as it is understood that that is what they are. >However, wording to *require* that behavior is not present in >the standard. Hence any program that makes use of the ambiguity is >nonstandard conforming. You are correct in stating that standard does not require any particular behavior when confronted by a program that is not standard-conforming. As I have explained, there is no ambiguity: the program most definitely is not standard-conforming. The compiler may do absolutely anything it likes with the program, including refusing to compile it. Dave Seaman -- Dave Seaman ags@j.cc.purdue.edu
smryan@garth.UUCP (Xxxxxx Xxxx) (12/16/88)
> DO I=A,B > IF (cond) GOTO 10 > DO J=C,D > code > 10 CONTINUE > end do J > end do I > more code > >That is, because the DO J loop used label 10 as its final statement, >its end appears just *after* the continue statement. The `IF' therefore >jumps into its loop. This is precisely the internal data structure used in FTN200. The FTN200 reference manual explicitly excludes the case of jumping to a common end label from outer loops. -- -- x x xxxx +------------------------------------+-----------------------------------------+ |`Xx X-Xxxx xx xxxxx Xxxxxxx xxxxx, |`Xxxxx xx xxxxxx xxx xxxx xxx | | Xxxxxxx xxx'x xxxxxx.' |xxxxxxxxxxxxxx xxx xxxxx xxxx xxxxxxx xxx| | -Xxxxxx Xxxx |xx. Xx xxxx xx xx xx xxxxxxxxx.' -X Xxxx| +------------------------------------+-----------------------------------------+
phinker@eta.unix.ETA.COM (Paul Hinker) (12/16/88)
In article <1136@ncar.ucar.edu>, pack@acdpyr.ucar.edu (Dan Packman) writes: > I ran the following horrible code: Horrible code deleted ... > System K > ======================================== > Pyramid OSX4.0 80 > SUN OS 4.0 92 > VAX/VMS 4.7 92 > CRAY COS1.15 [Warning notice from compiler, infinite loop generated] > > I think this particular case (with the numbered line not being a continuation) > should be flagged illegal. "To every do loop, a continue" (or end do) I ran the above code on a couple other machines and thought I'd post the results to show what kind of range there was for this simple test case : System K ------ --- Cyber 855 Nos 2.5.3 82 Cyber 205 Vsos 237 Fatal compilation error (Transfer inside DO) Eta-10Q R0120N2 Fatal compilation error (Transfer inside DO) Apollo DN 3000 Aegis 9.7 65785 How do PC-Fortrans handle this little beauty? Could someone post the results. > Dan Packman NCAR INTERNET: pack@acdpyr.UCAR.EDU > (303) 497-1427 P.O. Box 3000 CSNET: pack@ncar.CSNET > Boulder, CO 80307 DECNET SPAN: 9.367::PACK Paul Hinker Eta Systems, Inc. INET : phinker@aring.ETA.COM --- Looking for something snappy to put here ---
steve@oakhill.UUCP (steve) (12/17/88)
<1136@ncar.ucar.edu> <828@wilbur.unix.ETA.COM> Reply-To: steve@devsys.UUCP () Organization: Motorola Inc., Austin Tx. Keywords: branching doloops I requested with the original posting of the code, that people Email me the results, and I'll post them. Since I am still recieveing mail, I am holding off posting for now. Do not worry if you think your mail will duplicate some result already sent, Please send it anyway (I only just got a SUN result today). In article <828@wilbur.unix.ETA.COM> phinker@eta.unix.ETA.COM (Paul Hinker) writes: > > How do PC-Fortrans handle this little beauty? Could someone post the >results. > I have not recieved any PC results yet. (hint, hint) Please Email what you think this code should generate too (and why). Also please do not send me any flames on how horrible the code is. It was ment to be ugly, ambigous, and a rough test. 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) ----------------------------------------------------------------------------
hirchert@uxe.cso.uiuc.edu (12/17/88)
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 Applicationsdorn@fabscal.UUCP (Alan Dorn Hetzel) (12/17/88)
I missed the code, could some helpful person mail it to me. gatech.edu!fabscal!dorn
dph@lanl.gov (David Huelsbeck) (12/20/88)
From article <22994@sgi.SGI.COM>, by bron@bronze.SGI.COM (Bron Campbell Nelson): > A random question for you all: How does your Fortran compiler > handle branches to a DO loop termination statement? In particular, > in the following program, statement "10" terminates both DO loops, and > is branched to by a statement in the outer DO loop: > > subroutine foo(a, b, n) > real a(n), b(n,n) > do 10 i = 1,n > if (a(i) .eq. 0) goto 10 > do 10 j = 1,n > b(i,j) = 1/a(i) > 10 continue > > return > end > [...How various compilers treat it...Is it really leagal?...] > > -- > Bron Campbell Nelson bron@sgi.com > The opinions expressed are not necessarily those of the author's employer, > are not necessarily those of the author's friends, are not necessarily even > those of the author, and are probably not necessary. This caught my attention because I'm right in the middle of evaluating a number of different static analysis tools for FORTRAN that are supposed to catch this sort of thing. What follows are the results of using one such package on the code you provided. I'm giving only the Toolpack/1 results as it's the only non-comercial package we're looking at right now. -results-of-running-the-original-code-through-the-pfort-portablility-analyzer- ISTLA - Toolpack Static Analyser, Version 1.2 Error: Branch into DO with label - 10 at statement 5 in FOO detected at N@<end-of-statement> (token number 51) Error: Invalid forward reference to - 10 at statement 7 in FOO detected at <end-of-statement>@10 (token number 66) [ISTLA Terminated, 2 parse errors] Tool Termination Status: ERROR Errors detected. Invoke script "getlst" to obtain a listing showing statement and token numbers. ----------------------------------------------------------------------------- The Toolpack/1 source code structurer rufuses to even try to figure out what the programmer intended. This is interesting as we recently found a very similar bug deep down in a large mathematical library that was almost the exact same situation. It was however caused by a typo in the statement labels not by programmer intent. And just to fill out your list of compiler results: SunOS 3.5 f77 says nothing about it. Cray CFT gives a warning Cray CFT77 also gives a warning. David Huelsbeck dph@lanl.gov
steve@oakhill.UUCP (steve) (01/04/89)
In article <583@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > > In message-ID: <1750@devsys.oakhill.UUCP>, Steven R Weintraub, > Motorola Inc. Austin, Texas--cs.utexas.edu!oakhill!devsys!steve, > summarized the results of his "UGLY" code problem run on about 24 > different compilers. The test problem was: > > > 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 > > Half of the fortran implementations produced an ERROR diagnostic; > the other half gave numeric answers having the disparate values 80, > 82 or 92. > > Steve has shown that the USENET can be used to rapidly discover > ambiguities in a language standard. Discussions in this newsgroup > can propose corrective language to eliminate ambiguities from > the standard. The real problem is how to incorporate the new > language in a standard that has been chiseled in stone? Must > we wait for FORTRAN8x? :-( I think you now understand the reason I posted the example. This case was so ambigous that there were three correct responses, and a large portion of machines generated wrong responses. If you remember my initial post, I said there should be an unambigous interpretation for this code, and I gave four choices to decide on. These were: 1) Code is illegal. This interpretaion is what some people in the ANSI committee probably want. Unfortunately I think the standard on this point is to vague. Also it flies in the face of common coding practice. 2) Code is illegal, except where the last statement is a continue statement. This solves the ambigous interpretations for this code, but is slightly arbitrary. 3) That the code should interpret the K = K + 1 as part of the internal loop. This is probably what the writer of such code had in mind when writing it. It also makes compiler generation easy. 4) That the code K = K + 1 is part of both loops. This is messy, proabably not what the programmer had in mind, and the attempt to generate this code is what caused most of the compilers tested generate the result 92. In my concurrent postings, I state there needs to be a way to input user desires to the standard committees. The net might be one such source. So let's discuss. I personally believe that choice #3 is best. It allows for current user practice (or some say misunderstanding) of FORTRAN while clearing out the ambiguity. I also think this would be what most users intend when they code like this. Since I put a CONTINUE on every label, I technically avoid this ambiguity. I personally believe #1 is out of the question. The job of a standards committee should be to define standard use and expand it unobstructively as new theory as structures arise. Since this structure seems to be in standard use, saying it is illegal oversteps what I think a standards committee should do. What do you folks think. 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) ----------------------------------------------------------------------------
khb%chiba@Sun.COM (Keith Bierman - Sun Tactical Engineering) (01/04/89)
In article <1762@devsys.oakhill.UUCP> steve@oakhill.UUCP (steve) writes: >In article <583@mbph.UUCP>, > bad code repeated (yet again) >I think you now understand the reason I posted the example. This >case was so ambigous that there were three correct responses, and a >large portion of machines generated wrong responses. As several people posted, (even w/o recourse to the offical x3j3 response) the code is not compliant with the standard. This is NOT AMBIGOUS it is simply wrong code. >If you remember >my initial post, I said there should be an unambigous interpretation >for this code, and I gave four choices to decide on. These were: > >1) Code is illegal. This interpretaion is what some people in the > ANSI committee probably want. Unfortunately I think the standard > on this point is to vague. Also it flies in the face of common > coding practice. I have been involved in many end-user projects over 10 years, and have only seen this construct a couple of times...and it was the source of WRONG RESULTS in all cases. (otherwise I would not have been reading that module!). The fact that it works on some machines is totally irrelevant. > >In my concurrent postings, I state there needs to be a way to input >user desires to the standard committees. The net might be one such source. The current way is to write to x3j3. An address you may use is Jeanne Adams, Chair X3J3, Scientific Compting Division, NCAR, Box 3000, Boulder, Colorado 80307. The net is wonderful, and you can submit suggestions to any committee member by email. >So let's discuss. I personally believe that choice #3 is best. It allows >for current user practice (or some say misunderstanding) of FORTRAN while ------------------------- Please post a survey of some large codes (covering say 2 million lines) and tell us what % of the code contains this construct. I have several million lines under my belt, and have seen it twice, and it was wrong in both cases. >clearing out the ambiguity. I also think this would be what most users >intend when they code like this. Since I put a CONTINUE on every label, >I technically avoid this ambiguity. I personally believe #1 is out of the >question. The job of a standards committee should be to define standard >use and expand it unobstructively as new theory as structures arise. >Since this structure seems to be in standard use, saying it is illegal >oversteps what I think a standards committee should do. What do you >folks think. The standard said it is wrong. Compiler writers chose to not look for possible errors, but allow their algorithms to do whatever seems best. If you would like a compiler to not allow ANYTHING that is not in the standard, start using Ada. Your theory is good, please find an example which is relevant. The f88 document has several such (namelist, better definition of end=, etc.). Of course, this would be evidence that the current systems works the way you suggest a future organization should. > > 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) >---------------------------------------------------------------------------- Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus