cliff@wesson.phys.ucalgary.ca (Cliff Marcellus) (06/18/91)
I've discovered an interesting 'glitch' in the f77 compiler for
MIPS (and consequently, for SGI, also). given a code skeleton of :
if (...) goto 10
.
.
.
do 10 ....
.
.
.
10 continue
From the above, if the 'if' evaluates to TRUE, then the following code,
including the DO loop are supposed to be skipped. This doesn't happen
under MIPS-fortran. Instead, the loop-code is executed using a value
of "whatever" for the control loop variable. Now (personally) I don't
see that as a compiler bug, more a case of antequated coding style.
(ie. the purpose of the '10 continue' becomes ambigous). Anyway, I thought
I would post this in case others are suffering program failures for the
same or similiar reason. BTW : the fix to the above is of the form :
if (...) goto 11
.
.
.
do 10 ....
.
.
.
10 continue
11 continue
ttfn
--
Cliff Marcellus | Internet : cliff@phys.ucalgary.ca
Department of Physics and Astronomy | SPAN : CANCAL::CLIFF
The University of Calgary
OPINIONS EXPRESSED WITHIN ARE MY OWN AND NOT THOSE OF THE UNIVERSITY OF CALGARYzdenko@katzo.rice.edu (zdenko tomasic) (06/18/91)
In article <1991Jun17.174155.13484@cpsc.ucalgary.ca> cliff@phys.ucalgary.ca writes: >I've discovered an interesting 'glitch' in the f77 compiler for >MIPS (and consequently, for SGI, also). given a code skeleton of : > > if (...) goto 10 ^^ jump into the body of the loop from outside! (the continue statement is a part of the loop) > . > . > . > do 10 .... > . > . > . >10 continue ^^ This jump is illegal fortran, so anything can happen at the execution time. > >From the above, if the 'if' evaluates to TRUE, then the following code, >including the DO loop are supposed to be skipped. This doesn't happen >under MIPS-fortran. Instead, the loop-code is executed using a value >of "whatever" for the control loop variable. Now (personally) I don't >see that as a compiler bug, more a case of antequated coding style. >(ie. the purpose of the '10 continue' becomes ambigous). Anyway, I thought >I would post this in case others are suffering program failures for the >same or similiar reason. BTW : the fix to the above is of the form : > > > if (...) goto 11 > . > . > . > do 10 .... > . > . > . > 10 continue > 11 continue > The above is most likely the proper fix for the program bug. >ttfn > >-- >Cliff Marcellus | Internet : cliff@phys.ucalgary.ca >Department of Physics and Astronomy | SPAN : CANCAL::CLIFF >The University of Calgary >OPINIONS EXPRESSED WITHIN ARE MY OWN AND NOT THOSE OF THE UNIVERSITY OF CALGARY -- ___________________________________________________________________ Zdenko Tomasic, Rice U., Chem. Dept., P.O. Box 1892, Houston, Tx 77251 INTERNET: zdenko@katzo.rice.edu ___________________________________________________________________
calvin@dinkum.wpd.sgi.com (Calvin H. Vu) (06/19/91)
In <1991Jun17.224729.15190@rice.edu> zdenko@katzo.rice.edu (zdenko tomasic) writes: | In article <1991Jun17.174155.13484@cpsc.ucalgary.ca> cliff@phys.ucalgary.ca writes: | >I've discovered an interesting 'glitch' in the f77 compiler for | >MIPS (and consequently, for SGI, also). given a code skeleton of : | > | > if (...) goto 10 | ^^ jump into the body of the loop from outside! | (the continue statement is a part of the loop) | > . | > do 10 .... | > . | >10 continue | ^^ | This jump is illegal fortran, so anything can happen at the execution time. This is illegal and I have fixed it to give an error message when it happens. Later I changed the error into a warning since some people may want to control the unpredictability of their program execution rather than to do things the right and predictable way. It will be in SGI's 4.0 release. -- ----------------------------------------------------------------------------- Calvin H. Vu | "We are each of us angels with only one Silicon Graphics Computer Systems | wing. And we can only fly embracing calvin@sgi.com (415) 962-3679 | each other."
cliff@wesson.phys.ucalgary.ca (Cliff Marcellus) (06/19/91)
In article <1991Jun18.191622.4008@odin.corp.sgi.com>, calvin@dinkum.wpd.sgi.com (Calvin H. Vu) writes: |> In <1991Jun17.224729.15190@rice.edu> zdenko@katzo.rice.edu (zdenko tomasic) writes: |> |> | In article <1991Jun17.174155.13484@cpsc.ucalgary.ca> cliff@phys.ucalgary.ca writes: |> | >I've discovered an interesting 'glitch' in the f77 compiler for |> | >MIPS (and consequently, for SGI, also). given a code skeleton of : |> | > |> | > if (...) goto 10 |> | ^^ jump into the body of the loop from outside! |> | (the continue statement is a part of the loop) |> | > . |> | > do 10 .... |> | > . |> | >10 continue |> | ^^ |> | This jump is illegal fortran, so anything can happen at the execution time. Many thanks to all that pointed out that jumping into a loop is illegal. But strictly speaking, the above is not illegal. Older f77 compilers understood that this meant to skip over the code from the 'if' to the '10 continue'. (example: the 4.3BSD (circa '87) compiler handles this code just fine and produces the *correct* results. Anyway, it really just a look into the past (f66) since it is bad coding style! {-8 |> |> This is illegal and I have fixed it to give an error message when |> it happens. Later I changed the error into a warning since some people |> may want to control the unpredictability of their program execution |> rather than to do things the right and predictable way. It will be |> in SGI's 4.0 release. |> Super! BTW : the MIPS (and SGI??) V2.11 compilers missed this anomaly. I recently tried the MIPS V2.20 f77 and it flags this as a fatal error...
riley@theory.TC.Cornell.EDU (Daniel S. Riley) (06/19/91)
In article <1991Jun19.133207.24629@cpsc.ucalgary.ca>, cliff@phys.ucalgary.ca writes: >>>I've discovered an interesting 'glitch' in the f77 compiler for >>>MIPS (and consequently, for SGI, also). given a code skeleton of : >>> >>> if (...) goto 10 >>> . >>> do 10 .... >>> . >>>10 continue > Many thanks to all that pointed out that jumping into a loop is illegal. > But strictly speaking, the above is not illegal. Older f77 compilers > understood that this meant to skip over the code from the 'if' to the > '10 continue'. (example: the 4.3BSD (circa '87) compiler handles this > code just fine and produces the *correct* results. Anyway, it really > just a look into the past (f66) since it is bad coding style! {-8 Just because some compiler accepts it and does what you want does not mean that it is legal code. To quote chapter and verse, from ANSI X3.9-1978 (FORTRAN 77), page 11-6, 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 statment of the DO-Loop. and page 11-9, 11.10.8 Transfer into the range of a DO-Loop. Transfer into the range of a DO-Loop from outside of the loop is not permitted. Since the terminal statement is part of the range of the DO-Loop, the code above is unambiguously illegal, strictly speaking, according to the ANSI FORTRAN 77 standard. -- -Dan Riley (riley@theory.tc.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) (06/20/91)
In article <1991Jun19.162129.2870@batcomputer.tn.cornell.edu>, riley@theory.TC.Cornell.EDU (Daniel S. Riley) writes: > In article <1991Jun19.133207.24629@cpsc.ucalgary.ca>, > cliff@phys.ucalgary.ca writes: > >>>I've discovered an interesting 'glitch' in the f77 compiler for > >>>MIPS (and consequently, for SGI, also). given a code skeleton of : > >>> > >>> if (...) goto 10 > >>> . > >>> do 10 .... > >>> . > >>>10 continue > > > Just because some compiler accepts it and does what you want does > not mean that it is legal code. To quote chapter and verse, from > ANSI X3.9-1978 (FORTRAN 77), > This is all very well but I would like to point out that Mips does market their Fortran compiler as VMS fortran compatible and this is a *big* selling point. I don't know any physicist who would go out of their way to buy an ansi f77 compiler. In our case for example, when we were evaluating workstations, we essentially vetoed HP on account of their fortran compiler. (The 800 series one I considered particularly fussy.) Why is this important? I don't want to start a flame war (I was brought up on Burroughs Algol and am simply stating facts not personal preferences) but in physics the major programming language is fortran. It has always been and always will be (as far as I can see). Many of us have huge codes written in Fortran which work on other machines (until recently Vaxen were very popular in physics but IBM and others can be included as machines on which this code runs). Nobody wants to suffer major hassles porting these programs to other platforms. I have seen major labs veer away from certain workstation vendors because of the perceived difficulty in getting existing programs to compile on their product. Also physicists collaborate a lot, exchanging programs and visiting collaborators. Nobody wants to spend half of their visit with their collaborator debugging their programs all over again. The Mips compiler has a lot of useful flags for those who believe fortran is defined by past usage and not some self-appointed expert from ansi e.g. -static is a godsend for many users here; -r8 is also very useful for those moving from a Cray with it's default double precision. Mips also offer a flag for those who want to check that their code conforms to standards. Hence I would like to advocate that Mips adopt the philosophy that their compiler should compile code like that in the above example, perhaps with a warning or perhaps only if some flag is set, but it should be possible to compile the program **and correctly execute it** without rewriting it. (Could there ever be any problem with jumping to a continue statement at the end of a do loop?) If Mips do not want to adopt this philosophy then they should stop marketing their compiler as VMS compatible. (I am aware that there are some incompatibilities acknowledged by Mips but for the most part they are rather arcane.) Now to finish with a couple of technical examples of standards gone crazy: 1) Very similar, if not identical, to the one above. We had a visitor from Germany whose program ran on a Vax, an IBM and a Convex (and probably a Cray) but our Mips spewed garbage. The problem was traced to a construct like do 10 ... ... if (...) goto 10 do 10 ... ... 10 continue The use of a single continue as the last statement in overlapping do loops is apparently allowed -- the Mips fortran manual says so -- but as above the goto failed. (I may not have recalled the exact construction but there was no compiler error, just wrong results.) Using two distinct continue statements cured this guy's problem. Not hard to fix you may say but a waste of much time surely. 2)There is an obscure rule in f77 which requires that data statements come after declarations and before the other program statements. Most compilers don't require this (and I have a suspicion that earlier versions of the Mips compiler did not either or we probably would not have bought a Mips) but somebody in their wisdom has decided that the Mips compiler will conform with the standard. Please, how about a flag that will let this pass. Paul Bickerstaff Internet: pbickers@tamaluit.phys.uidaho.edu Physics Dept., Univ. of Idaho Phone: (208) 885 6809 Moscow ID 83843, USA FAX: (208) 885 6173
k2@bl.physik.tu-muenchen.de (Klaus Steinberger) (06/20/91)
pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) writes: >2)There is an obscure rule in f77 which requires that data >statements come after declarations and before the other >program statements. Most compilers don't require this (and >I have a suspicion that earlier versions of the Mips compiler did >not either or we probably would not have bought a Mips) >but somebody in their wisdom has decided that the Mips compiler >will conform with the standard. Please, how about a flag that will >let this pass. I've written a PSR to CDC regarding this just yesterday. Today, they told me that the next version of the compiler (2.20) of the compiler accepts the intermixing of declaration and data statements. Sincerely, Klaus Steinberger -- Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen Phone: (+49 89)3209 4287 Hochschulgelaende FAX: (+49 89)3209 4280 D-8046 Garching, Germany BITNET: K2@DGABLG5P Internet: k2@bl.physik.tu-muenchen.de
rrr@u02.svl.cdc.com (Rich Ragan) (06/21/91)
In <1991Jun20.075058.10576@groucho> pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) writes: >In article <1991Jun19.162129.2870@batcomputer.tn.cornell.edu>, >riley@theory.TC.Cornell.EDU (Daniel S. Riley) writes: >> In article <1991Jun19.133207.24629@cpsc.ucalgary.ca>, >> cliff@phys.ucalgary.ca writes: >> >>>I've discovered an interesting 'glitch' in the f77 compiler for >> >>>MIPS (and consequently, for SGI, also). given a code skeleton of : >> >>> >> >>> if (...) goto 10 >> >>> . >> >>> do 10 .... >> >>> . >> >>>10 continue >> >> >> Just because some compiler accepts it and does what you want does >> not mean that it is legal code. To quote chapter and verse, from >> ANSI X3.9-1978 (FORTRAN 77), >> >The Mips compiler has a lot of useful flags for those who believe >fortran is defined by past usage and not some self-appointed expert >from ansi e.g. -static is a godsend for many users here; -r8 is also >very useful for those moving from a Cray with it's default double >precision. The -r8 flag helps but it doesn't help much if you have integers and reals equivalenced or in common and overlapping because the integers don't get padded to 8 bytes and so your storage alignment is off and weird and wonderful things can happen. Mips also offer a flag for those who want to check that >their code conforms to standards. Unless a lot of work has been done in 2.20 (I think not), you will find that the flag exists but there is no implementation behind it to actually do any checking. >Hence I would like to advocate >that Mips adopt the philosophy that their compiler should compile >code like that in the above example, perhaps with a warning or perhaps >only if some flag is set, but it should be possible to compile the program >**and correctly execute it** without rewriting it. (Could there ever be >any problem with jumping to a continue statement at the end of a do loop?) The real problem is that since it is non-standard, two vendors may have differing implementations thus screwing up portability and creating a rather hard to find bug. The original code could be defined to mean 1) transfer to the CONTINUE from outside causes a fall through to the next statement. This is the probably what was wanted and the user wanted to avoid inventing another label to get to the statement after the loop. 2) transfer to the end of the loop and continue the iteration. This might be construed as somehow skipping the first iteration although the user would have to initialize the loop control variable manually. 3) Or (most likely) this is a FORTRAN 66 piece of code using what was called the "Extended Range of a DO loop whereby the user could transfer out of the DO loop, do some work and then GO TO back into the DO loop and take up where they left off. What was not shown was any transfer out so I can't say for sure that this is what was intended. The -66 option of the Mips compiler may (or may not) allow this to work. I haven't tried it yet. Case 1 and Cases 2/3 call for very different bits of object code to implement them. If one wanted to advocate anything approaching "standard" then case 3 is the only really supportable one because it was once a standard but is no longer "standardized" by ANSI/ISO but can still be found in existing usage. >If Mips do not want to adopt this philosophy then they should stop >marketing their compiler as VMS compatible. (I am aware that there >are some incompatibilities acknowledged by Mips but for the most >part they are rather arcane.) >Now to finish with a couple of technical examples of standards gone >crazy: >1) Very similar, if not identical, to the one above. We had a visitor >from Germany whose program ran on a Vax, an IBM and a Convex >(and probably a Cray) but our Mips spewed garbage. The problem >was traced to a construct like > do 10 ... > ... > if (...) goto 10 > do 10 ... > ... > 10 continue >The use of a single continue as the last statement in overlapping do >loops is apparently allowed -- the Mips fortran manual says so -- >but as above the goto failed. (I may not have recalled the exact >construction but there was no compiler error, just wrong results.) >Using two distinct continue statements cured this guy's problem. >Not hard to fix you may say but a waste of much time surely. This too is not legal per the current FORTRAN standard or even the FORTRAN 66 standard. "Wrong" results should not be countenanced. At the very minimum, a diagnostic is required on the part of the Mips compiler. This case pretty much offers a commonsense interpretation an no vendor is likely to guess wrong. and increment the inner DO when the transfer occurs from the outer. What the user wants is to go to the next iteration of the outer DO. >2)There is an obscure rule in f77 which requires that data >statements come after declarations and before the other >program statements. Most compilers don't require this (and >I have a suspicion that earlier versions of the Mips compiler did >not either or we probably would not have bought a Mips) >but somebody in their wisdom has decided that the Mips compiler >will conform with the standard. Please, how about a flag that will >let this pass. The actual rules from FORTRAN 66 and FORTRAN 77 standards is that they must appear after all declarations and may appear among executable statements. Allowing them to appear among the declarations creates a problem if the object has not yet been declared because the compiler does not know its type, whether it's an array, if so how big, etc. IBM first relaxed this a bit by allowing data initialization in type statements. This rule is really for the convenience of compiler writers and somewhat for making compilers efficient/fast since otherwise you have to hang on to some DATA statements until you can figure out how to process them (not to mention being unable to easily put diagnostics next to the statements in the source listing should something turn out to be wrong.) -- Richard R. Ragan rrr@svl.cdc.com (408) 496-4340 Control Data Corporation - Silicon Valley Operations 5101 Patrick Henry Drive, Santa Clara, CA 95054-1111
jason@dsd.es.com (Jason S. Ehrhart) (06/21/91)
Paul Bickerstaff writes: |> I would like to point out that Mips does market |> their Fortran compiler as VMS fortran compatible and this is a *big* |> selling point. There is a -vms flag, but the documentation doesn't get into detail about what is VMS-Compatible. It states that Mips provides full VMS Fortran compatibility to the extent possible without the VMS os or VAX data representation. A little ambiguous there, perhaps it will be made clearer in a future release of the doc set. Originally, the -vms flag did very little. It does more now. But obviously not as much as you'd like. |> Hence I would like to advocate |> that Mips adopt the philosophy that their compiler should compile |> code like that in the above example, perhaps with a warning or perhaps |> only if some flag is set, but it should be possible to compile the program |> **and correctly execute it** without rewriting it. (Could there ever be |> any problem with jumping to a continue statement at the end of a do loop?) Mips is aware of this problem. To briefly explain, there are two distinct types of statement labels. There are Do-Loop terminal statements, and then there are goto target statements. When the compiler front-end goes through the code, it treats these two types of statements seperately. So, the tricky code which handles Do-Loops can get in the way of the straight forward goto code, hence the bizarre behavior. I've looked at the compiler source code for this, it is not pretty. It will be a significant rewrite to change this. I am not sure of when you will see this "fixed" any better than just being flagged. There is an an error message put into the 2.20 release which does flag this problem. The work-around is already known (seperate statements for doloops and goto's), it will not make your code any less portable to make this change. |> 1) Very similar, if not identical, to the one above. We had a visitor |> from Germany whose program ran on a Vax, an IBM and a Convex |> (and probably a Cray) but our Mips spewed garbage. The problem |> was traced to a construct like |> |> do 10 ... |> ... |> if (...) goto 10 |> do 10 ... |> ... |> 10 continue I saw this when I was at Mips, this is the exact same problem. In fact, I filed the bug report on it. I do have to make a point about the documentation. On page 6-8 of Part 2 of the Fortran Language Reference Manual. It is explicitly stated under Restrictions that: 4. A program must not transfer control into the range of a DO-loop from outside the DO-loop. Both of your examples shown here violate this restriction. |> The use of a single continue as the last statement in overlapping do |> loops is apparently allowed -- the Mips fortran manual says so -- You'd have to show me where the documentation sez this. You might have misunderstood rule number 4 on page 6-8 which states: "The same statement may serve as the terminal statement in two or more nested DO-Loops. The problem here is that there is a goto which is transfering control into the range of a DO-Loop, thus violating restriction number 4. |> 2)There is an obscure rule in f77 which requires that data |> statements come after declarations and before the other |> program statements. This was a problem with revs before 2.20, it is now fixed. Put your DATA statements where you wish. |> Please, how about a flag that will let this pass. We're working on getting it to work correctly without a flag, it just takes a little time and effort. -- jason ehrhart jason@dsd.es.com evans and sutherland 580 arapeen drive Perspective, use it or lose it. salt lake city, ut, 84158 (801) 582-5847 x4812
diamond@jit533.swstokyo.dec.com (Norman Diamond) (06/21/91)
In article <1991Jun20.075058.10576@groucho> pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) writes: >>>>> if (...) goto 10 >>>>> . >>>>> do 10 .... >>>>> . >>>>>10 continue >The Mips compiler has a lot of useful flags for those who believe >fortran is defined by past usage By past usage, eh? In Fortran-66, DO loops could have extended ranges. It was REQUIRED for the do-loop in the quoted example to be executed after the goto (unless incrementing the index puts it over the upper bound in the do statement, in which case the loop exits). So this seems to be a complaint that the compiler conforms to too many past usages, eh? >and not some self-appointed expert from ansi Well, a few experts are appointed by their employers, but otherwise, yes the experts are self-appointed. ANSI is not the military and does not conscript involuntary members. You should appoint yourself and get several of your friends to appoint themselves, and join the ANSI committee. One voice can make a difference, but several are more powerful. >1) Very similar, if not identical, to the one above. We had a visitor >from Germany whose program ran on a Vax, an IBM and a Convex >(and probably a Cray) but our Mips spewed garbage. The problem >was traced to a construct like > do 10 ... > ... > if (...) goto 10 > do 10 ... > ... > 10 continue >The use of a single continue as the last statement in overlapping do >loops is apparently allowed -- the Mips fortran manual says so -- Yes, the last statement is in the range of both do-loops. >but as above the goto failed. Yes, because the goto is not in the range of the second do-loop, and the continue IS in the range of the second do-loop. >(I may not have recalled the exact >construction but there was no compiler error, just wrong results.) You mean right results. The program got what it asked for. >Using two distinct continue statements cured this guy's problem. Yes, when the programmer asked for what he wanted, instead of asking for something different, it worked wonders. >Not hard to fix you may say but a waste of much time surely. If learning to program is a waste of time, it sounds like you're in the wrong profession. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. Permission is granted to feel this signature, but not to look at it.
pbickers@tamaluit.phys.uidaho.edu (Paul Bickerstaff) (06/26/91)
In article <1991Jun20.213433.24193@dsd.es.com>, jason@dsd.es.com (Jason S. Ehrhart) writes: > > There is a -vms flag, but the documentation doesn't get into detail > about what is VMS-Compatible. It states that Mips provides full VMS Fortran > compatibility to the extent possible without the VMS os or VAX data > representation. A little ambiguous there, perhaps it will be made > clearer in a future release of the doc set. Originally, the -vms > flag did very little. It does more now. But obviously not as much as > you'd like. > Can anybody provide details on what the -vms flag really does? The man pages suggest it does very little: -vms Cause the runtime system to behave like VMS Fortran with regard to interpreting carriage control on unit 6. (We're still on RISCos 4.51 and fortran 2.11) If there's "more now" I'd like to know. Thanks. Paul Bickerstaff Internet: pbickers@tamaluit.phys.uidaho.edu Physics Dept., Univ. of Idaho Phone: (208) 885 6809 Moscow ID 83843, USA FAX: (208) 885 6173