Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!malgudi!caen!spool.mu.edu!cs.umn.edu!uc!shamash!rrr From: rrr@u02.svl.cdc.com (Rich Ragan) Newsgroups: comp.sys.mips Subject: Re: f77 compiler bug (both MIPS and SGI) Message-ID: <34362@shamash.cdc.com> Date: 20 Jun 91 17:20:05 GMT Article-I.D.: shamash.34362 References: <1991Jun19.162129.2870@batcomputer.tn.cornell.edu> <1991Jun17.224729.15190@rice.edu> <1991Jun18.191622.4008@odin.corp.sgi.com> <1991Jun19.133207.24629@cpsc.ucalgary.ca> <1991Jun20.075058.10576@groucho> Sender: usenet@shamash.cdc.com Reply-To: rrr@svl.cdc.com Organization: Control Data Corporation, Silicon Valley Operations Lines: 135 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