sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/14/89)
The Fortran-77 standard _was_ accepted 11 years ago,
so one would suppose that the compiler writers have already
taken notice. Well... take this very simple example of an
_incorrect_ Fortran programme:
INTEGER I, J
IF (I .LT. 100000) GOTO 2
DO 9 I = 1, 10
2 J = I * I
WRITE (6, 100) I, J
9 CONTINUE
100 FORMAT (2I12)
END
It contains a GOTO into a DO loop, which is illegal in Fortran-77.
Furthermore, very trivial static analysis could detect that the GOTO
here cannot be legal even according to the "extended range" rules
of Fortran-66.
I just tried this kind of example once again with Digital's VAX/VMS
Fortran compiler, turning on all possible STANDARD and WARNING switches
(I should think). The result: it compiled without the slightest complaint.
Then I tried the same with Sun's Fortran 77 compiler (with the -ansi
option), and it behaved likewise.
Jumping into a DO loop can easily happen as a kind of clerical error,
especially when old code is reworked. It can also cause puzzling
run-time effects so that it is difficult to find the original error.
Therefore detecting this error at compile time is very useful:
compilers should do their job!
The above-mentioned omission also makes one pessimistic about
how long even the most Fortran-oriented computer vendors will take
to really implement any Fortran-8X (or 9X?) standard,
even if such a standard becomes official.
Note: it was years ago that I last had to work with Fortran;
I just took up an old pet peeve.
Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finlandr4@cbnews.ATT.COM (richard.r.grady..jr) (09/15/89)
In article <1301@tukki.jyu.fi> markku@jytko.jyu.fi (Markku Sakkinen) SAKKINEN@FINJYU.bitnet (alternative) writes: > [ Markku complains that two Fortran-77 compilers (Digital's VAX/VMS > and Sun) do not complain about the illegal GOTO in the following > code.] > > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 > 2 J = I * I > WRITE (6, 100) I, J > 9 CONTINUE > 100 FORMAT (2I12) > END > > It contains a GOTO into a DO loop, which is illegal in Fortran-77. I tried this code with the f77 (Fortran-77) compiler on my Unix system (SYS V). It compiled without complaint. It also executed without complaint. There was only one line of output, and the result depended upon whether the output was directed to the standard output (terminal) or to a file: Output file I J <standard output> 0 2135329856 fort.out 0 -2147343360 2fort.out 0 1593912976 zzzzqqqqzqzq 0 -2146113776 -- Dick Grady r_r_grady@att.com ...!att!mvuxd!r4
nmm@cl.cam.ac.uk (Nick Maclaren) (09/16/89)
markku@jytko.jyu.fi (Markku Sakkinen) objects to the following erroneous construction not being flagged by the VMS or Sun Fortran compilers: > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 >2 J = I * I > WRITE (6, 100) I, J >9 CONTINUE >100 FORMAT (2I12) > END I fully agree! This all comes of using nasty systems like VAX/VMS and UNIX - we use IBM's VS Fortran under MVS/XA and it does diagnose that sort of error! [Please insert smileys to taste.] I am not currently an employee of IBM (nor even a shareholder) .... Nick Maclaren University of Cambridge Computer Laboratory nmm @ cl.cam.ac.uk
palle@dc.luth.se (Bertil P}lsson) (09/16/89)
In <1301@tukki.jyu.fi> markku@jytko.jyu.fi (Markku Sakkinen) writes > Well... take this very simple example of an > _incorrect_ Fortran programme: > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 > 2 J = I * I > WRITE (6, 100) I, J > 9 CONTINUE > 100 FORMAT (2I12) > END (Text deleted) > I just tried this kind of example once again with Digital's VAX/VMS > Fortran compiler, turning on all possible STANDARD and WARNING switches > (I should think). The result: it compiled without the slightest complaint. > Then I tried the same with Sun's Fortran 77 compiler (with the -ansi > option), and it behaved likewise. The current Norsk Data (ND) Fortran-compiler gives the following result, which I think is quite reasonable; a warning at compile time. Of course, if you neglect the warning you get an unpredictable result. f-5 illegal:for ND-500 ANSI 77 FORTRAN COMPILER - 210190K02 COMPILING: #MAIN LINE: 1 ** WARNING ** #MAIN 2: ' 2', BRANCH INTO DO/IF NEST - CPU TIME USED: 0.3 SECONDS. 8 LINES COMPILED. *** 1 WARNING - PROGRAM SIZE=83 DATA SIZE=120 COMMON SIZE=0 0 0 1 1 2 4 3 9 4 16 5 25 6 36 7 49 8 64 9 81 10 100 I also compiled and ran the program with Microsoft Fortran 4.1 on a PC/AT-clone. It also gives a warning, and produces the same output as for the ND compiler. Bertil Paulsson ! Internet : palle@mop.luth.se Division of Mineral Processing ! UUCP: ..{uunet,mcvax}!enea!mop.luth.se!palle Lulea University of Technology ! BITNET : palle%mop.luth.se@sekth S-951 87 LULEA ! Fax : +46-920-91199 Sweden ! Telex : 80447 LUH S
amull@Morgan.COM (Andrew P. Mullhaupt) (09/18/89)
The Sun 3 and Sun 4 machines both give me the following result of the "Branch illegally into DO-Loop" test program. f77 -ansi goof.f f77 -ansi -O goof.f (Either compiles with no warnings) Both run and produce the output: 0 0 1 1 2 4 etc. This seems odd, since the Sun f77 "compiler" is trying to support VMS extensions. It should therefore have behavior similar to that found previously on VMS machines. The only good UNIX fortran compiler is a dead UNIX fortran compiler. Andrew Mullhaupt, Opinions expressed here are my own are my own.
hallidayd@yvax.byu.edu (09/19/89)
Markku Sakkinen (sakkinen@tukki.jyu.fi) posed the following _incorrect_ Fortran program in message (<1301@tukki.jyu.fi>) > > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 >2 J = I * I > WRITE (6, 100) I, J >9 CONTINUE >100 FORMAT (2I12) > END > >It contains a GOTO into a DO loop, which is illegal in Fortran-77. >Furthermore, very trivial static analysis could detect that the GOTO >here cannot be legal even according to the "extended range" rules >of Fortran-66. > >I just tried this kind of example once again with Digital's VAX/VMS >Fortran compiler, turning on all possible STANDARD and WARNING switches >(I should think). The result: it compiled without the slightest complaint. I tried this problem on the updated (version 5.3) version of VAX/VMS Fortran with the following listing (I used the new SEMANTIC, STANDARD option --- STANDARD=SYNTAX is insufficient) 18-Sep-1989 12:54:50 VAX FORTRAN V5.3-50 Page 1 18-Sep-1989 12:52:00 $SCRATCH:[HALLIDAYD]TEMP.FOR;2 0001 INTEGER I, J 0002 IF (I .LT. 100000) GOTO 2 0003 DO 9 I = 1, 10 0004 2 J = I * I %FORT-I-EXTILBRNCH, Extension to FORTRAN-77: Nonstandard branch into block [ 2] in module TEMP$MAIN 0005 WRITE (6, 100) I, J 0006 9 CONTINUE 0007 100 FORMAT (2I12) 0008 END PROGRAM SECTIONS Name Bytes Attributes 0 $CODE 84 PIC CON REL LCL SHR EXE RD NOWRT LONG 1 $PDATA 5 PIC CON REL LCL SHR NOEXE RD NOWRT LONG 2 $LOCAL 4 PIC CON REL LCL NOSHR NOEXE RD WRT LONG Total Space Allocated 93 ENTRY POINTS Address Type Name 0-00000000 TEMP$MAIN VARIABLES Address Type Name Address Type Name 2-00000000 I*4 I ** I*4 J LABELS Address Label Address Label Address Label 0-0000001C 2 ** 9 1-00000000 100' 18-Sep-1989 12:54:50 VAX FORTRAN V5.3-50 Page 2 18-Sep-1989 12:52:00 $SCRATCH:[HALLIDAYD]TEMP.FOR;2 0001 COMMAND QUALIFIERS FORTRAN/STANDARD=(SEMANTIC)/LIST=TEMP TEMP /CHECK=(NOBOUNDS,OVERFLOW,NOUNDERFLOW) /DEBUG=(NOSYMBOLS,TRACEBACK) /SHOW=(NODICTIONARY,NOINCLUDE,MAP,NOPREPROCESSOR,SINGLE) /STANDARD=(SEMANTIC,NOSOURCE_FORM,NOSYNTAX) /WARNINGS=(NODECLARATIONS,GENERAL,NOULTRIX,NOVAXELN) /CONTINUATIONS=19 /NOCROSS_REFERENCE /NOD_LINES /NOEXTEND_SOURCE /F77 /NOG_FLOATING /I4 /NOMACHINE_CODE /OPTIMIZE /NOPARALLEL /NOANALYSIS_DATA /NODIAGNOSTICS /LIST=$SCRATCH:[HALLIDAYD]TEMP.LIS;1 /OBJECT=$SCRATCH:[HALLIDAYD]TEMP.OBJ;1 COMPILATION STATISTICS Run Time: 0.34 seconds Elapsed Time: 1.09 seconds Page Faults: 575 Dynamic Memory: 377 pages _____________________________________________________________________ / David Halliday \ | | | Internet: hallidayd@yvax.byu.edu or hallidayd@acoust.byu.edu | | BITNET: hallidayd@byuvax or hallidayd%acoust.byu.edu@utahcca | | Us Mail: BYU Physics Department | | 296 ESC | | Provo, UT 84602 | \_____________________________________________________________________/
hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (09/19/89)
In message <1301@tukki.jyu.fi> from sakkinen@tukki.jyu.fi, Markku Sakkinen, writes >The Fortran-77 standard _was_ accepted 11 years ago, >so one would suppose that the compiler writers have already >taken notice. Well... take this very simple example of an >_incorrect_ Fortran programme: > > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 >2 J = I * I > WRITE (6, 100) I, J >9 CONTINUE >100 FORMAT (2I12) > END > >It contains a GOTO into a DO loop, which is illegal in Fortran-77. It also contains another serious error; the variable I is used in an expression before it is assigned a value. Is that legal in X3.9-1978 fortran or is it just another allowed extension? Are there any implementations that detect this type of error? Why aren't all standard conforming compilers required to detect and report such errors? The following are the results obtained from the 3B2/XLA+ and the 3B1/SVS implementations: From a 3B2/XLA+: No warnings or diagnostics 0 0 1 1 2 4 ... etc etc*etc 10 100 From a 3B1/SVS: MC68000 FORTRAN 77 Compiler V2.2 21-May-84 4. *********** J <=== = I * I ***** Error number 102 in line 4 of file markku.for ***** ***** Illegal jump into block ***** 1 errors. 8 lines. File markku.for ---------------------------------------------------------------------- Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Department of Biophysics Home UUCP: uunet!mimsy!mbph!hybl!ah University of Maryland CoSy: ahybl School of Medicine Baltimore, MD 21201 Phone: (301) 328-7940 (Office) ----------------------------------------------------------------------
sjc@key.COM (Steve Correll) (09/21/89)
Markku Sakkinen writes: >The Fortran-77 standard _was_ accepted 11 years ago, >so one would suppose that the compiler writers have already >taken notice. Well... take this very simple example of an >_incorrect_ Fortran programme: > > INTEGER I, J > IF (I .LT. 100000) GOTO 2 > DO 9 I = 1, 10 >2 J = I * I > WRITE (6, 100) I, J >9 CONTINUE >100 FORMAT (2I12) > END > >It contains a GOTO into a DO loop, which is illegal in Fortran-77... >I just tried this kind of example once again with Digital's VAX/VMS >Fortran compiler, turning on all possible STANDARD and WARNING switches >(I should think). The result: it compiled without the slightest complaint. The Fortran 77 standard dictates what a compiler must do with a legal program, but permits a compiler to do anything it likes with an incorrect one. A standard-conforming compiler may silently abort, or print a treatise on good programming hygiene, or correct the error by guessing what you intended to do, or ignore your program and emit the Towers of Hanoi instead. See ANSI X3.9-1978 section 1.4. One may disagree with the permissiveness of the Fortran 77 committee (the Fortran 88 committee clearly does) but it is a mistake to say that the example above demonstrates anything about "standard conformance". My own opinion: 1. I think that the way a compiler deals with errors belongs to what the ANSI C committee call "quality of implementation", and when you shop for a compiler, you must judge this for yourself; no standard can ever entirely do this for you. For example, although the Fortran 88 standard requires a compiler to detect illegal syntax, it doesn't require error messages to cite line numbers. Thus, a compiler could conform merely by printing: "There was a syntax error somewhere in your program. Abort." Should the standard mandate that error messages contain line numbers? I think not. On a Macintosh, many text-editors do not use line numbers, so a compiler which printed error messages containing line numbers would be inferior to a compiler which showed me the source file with a finger or an arrow pointing at the offending line, plus a pop-up window containing the error message and a button marked "show next error". Better to let me, the compiler-shopper, judge the quality of implementation for myself. 2. Forbidding extensions is silly, so long as compilers can warn about them, because extensions are the proving-ground for the standards of the future. Besides, if extensions are the worst portability problem you face, you're living in paradise. If I give you a large piece of code with a single non-portable line inside it, you had better hope it's: BUFFER IN ... rather than: i_align(i) = iand(z'fff0', i) Every conforming Fortran 88 compiler which does not implement BUFFER IN as an extension will print an error message telling you about it. By contrast, the "i_align" statement function is perfectly legal Fortran 88, but no compiler can read the programmer's mind and tell you that this code probably stops doing what the programmer intended when you move it from a 16-bit machine to a 32-bit machine. -- ...{sun,pyramid}!pacbell!key!sjc Steve Correll
sakkinen@tukki.jyu.fi (Markku Sakkinen) (09/22/89)
-- Note: I am only forwarding the original: see below.
Markku Sakkinen --
*From: dab@oswego.oswego.edu (Dave Bozak)
*Message-Id: <8909170053.AA22598@oswego>
*Received: by oswego.Oswego.EDU (5.57/Osw4.1.6)
id AA22598; Sat, 16 Sep 89 20:53:44 EDT
*To: markku@jytko.jyu.fi
*Subject: fortran conformance
*Status: R
hi,
The following is in response to your posting in comp.lang.fortran.
Right now, it seems any postings from our machine never really get out into
the real world, so I thought I'd just mail a copy to you. If you wish
to post a copy of it, feel free.
-dave bozak
My two cents worth:
I have run into so many peculiarities using the f77 compiler
that comes with Ultrix, I insist my students run their code
through PFORT first. If it doesn't pass, don't bother compiling it.
Here is what I get when I send the program through NAG's
PFORT verifier (part of Toolpack):
1=>pfort test.f
ISTLA - Toolpack Static Analyser, Version 1.2
Error: Invalid forward reference to - 2 at statement 4 in $MAIN
detected at <end-of-statement>@2 (token number 23)
[ISTLA Terminated, 1 parse error]
Tool Termination Status: ERROR
Errors detected. Invoke script "getlst" to obtain a listing showing
statement and token numbers.
2=>getlst test.f
[ISTLX Normal Termination]
In the following listing, the first number is the statement number and
the second number is the number of the first token in the statement.
Statements are numbered within a program unit, tokens within the file.
Scanning errors are indicated. When a scanning error occurs, the
scanner resets and continues.
TOOLPACK FORTRAN 77 SCANNER - RELEASE 2
1 - 1 INTEGER I, J
2 - 6 IF (I .LT. 100000) GOTO 2
3 - 15 DO 9 I = 1, 10
4 - 23 2 J = I * I
5 - 30 WRITE (6, 100) I, J
6 - 40 9 CONTINUE
7 - 43 100 FORMAT (2I12)
8 - 49 END
/\ David Alan Bozak, Computer Science Department
/ \ SUNY College at Oswego, Oswego, NY 13126 (315) 341-2347
_____/____\_____ Internet: dab@rocky.oswego.edu
/ / \ \ or dab%rocky.oswego.edu@nisc.nyser.net
/____/ \____\ UUCP: {cornell!devvax,rutgers!sunybcs}!oswego!rocky!dabsakkinen@tukki.jyu.fi (Markku Sakkinen) (10/03/89)
In message <1301@tukki.jyu.fi> from sakkinen@tukki.jyu.fi, I presented a sample programme about an illegal jump into a DO loop, in which many current compilers are unable to find the error. In message <612@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl) writes: >... >It also contains another serious error; the variable I is used >in an expression before it is assigned a value. Is that legal >in X3.9-1978 fortran or is it just another allowed extension? >Are there any implementations that detect this type of error? >Why aren't all standard conforming compilers required to detect >and report such errors? The following are the results obtained >from the 3B2/XLA+ and the 3B1/SVS implementations: >... You are right: this was a lazily written example, although it was good enough to demonstrate the point I wanted. If there had been only an unconditional GOTO, many compilers would have given some warning like "No path to statement" (i.e., to the DO statement). In the following form, the other error would be eliminated: SUBROUTINE GOTODO (I) INTEGER I, J IF (I .LT. 100000) GOTO 2 DO 9 I = 1, 10 ... In general, the question of whether every variable is assigned a value before it is used in an expression cannot be determined at compile time. Namely, if a variable is used as an argument in a subroutine or function call, it _might_ be assigned a value there. Alternatively, the formal argument might be _used_ in the subroutine/function, thus requiring an assignment before the call. In article <1099@key.COM> sjc@key.COM (Steve Correll) writes: >... >The Fortran 77 standard dictates what a compiler must do with a legal program, >but permits a compiler to do anything it likes with an incorrect one. A >standard-conforming compiler may silently abort, or print a treatise on good >programming hygiene, or correct the error by guessing what you intended to >do, or ignore your program and emit the Towers of Hanoi instead. See ANSI >X3.9-1978 section 1.4. > >One may disagree with the permissiveness of the Fortran 77 committee (the >Fortran 88 committee clearly does) but it is a mistake to say that the example >above demonstrates anything about "standard conformance". > >My own opinion: > > 1. I think that the way a compiler deals with errors belongs to what the > ANSI C committee call "quality of implementation", and when you shop for a > compiler, you must judge this for yourself; no standard can ever entirely > do this for you. [...] >... > > 2. Forbidding extensions is silly, so long as compilers can warn about them, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > because extensions are the proving-ground for the standards of the future. >... The point I wanted to make was mainly: If a compiler is advertised to detect deviations from the standard, it should really do so as far as feasible! And allowing jumps into DO loops is certainly a "proving-ground" for the standards of the _past_! Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland
turpin@cs.utexas.edu (Russell Turpin) (10/07/89)
In article <612@mbph.UUCP>, hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > It also contains another serious error; the variable I is used > in an expression before it is assigned a value. Is that legal > in X3.9-1978 fortran or is it just another allowed extension? > Are there any implementations that detect this type of error? > Why aren't all standard conforming compilers required to detect > and report such errors? ... Some compilers will tell you, in the obvious cases, that a variable is used before it is assigned a value. But determining in general whether or not every (or any or no) run of a program will use a variable before it has assigned the variable a value is impossible. (Exercise for reader: reduce to the halting problem.) Like array subscript errors, this kind of problem can only be fully detected at run-time in the cases in which it occurs. Russell
sakkinen@tukki.jyu.fi (Markku Sakkinen) (10/20/89)
In message <1301@tukki.jyu.fi> from sakkinen@tukki.jyu.fi, I presented a sample programme about an illegal jump into a DO loop, in which many current compilers are unable to find the error. Larry Rolison from Unisys, who has no direct access to the Internet, sent me a letter pointing out that the latest FORTRAN compiler for the Unisys 1100/2200 family, in whose implementation team he has been a member, does in fact detect illegal branches into an IF block, WHERE block or DO-loop. The letter ends thus: "So don't be pessimistic about quality of implementation of FORTRAN compilers, either for FORTRAN 77 or Fortran 8x; those of us that really care will get it right." Let's hope he's right. There was a time when I had a slogan: "Don't mistake a Formula Translator for a programming language", but today it is perhaps more important to warn people: "Don't mistake a block-structured assembly language for a high-level programming language". Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland