jerry@violet.berkeley.edu ( Jerry Berkman ) (08/09/89)
According to the 1977 standard, pages 18-1 & 18-2, the symbolic
name of an external function is a global entity while the
symbolic name of an intrinsic function is a local entity.
And according to section 18.1.2:
"a symbolic name that identifies a local entity may,
in a different program unit, identify an entity of
any class that is either local to that program unit
or global to the executable program."
Given that background, I expect the following program to print a 4 and a 2:
intrinsic index
character str*10
str = 'abcdefghij'
print *, index(str,'d')
call sub(str)
end
subroutine sub(str)
character str*(*)
external index
print *, index(str,'d')
end
function index(str,ch)
character str*(*), ch*1
index = 2
end
It does using 4.3 BSD f77 on a VAX or DEC's VMS FORTRAN compiler.
However IBM's VS FORTRAN and Cray's CFT77 issue a warning during loading
and then print a 2 followed by a 2! I.e. they do not distinguish the
intrinsic from the external!
This came up because I was trying to install the "generic UNIX" version
of NAG's help facility, which has a block data named "index" in one
program and a main program named "index" in another program, and things
just weren't working ...
- Jerry Berkman, U.C.Berkeley
jerry@violet.berkeley.eduhybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) (08/15/89)
In message <1989Aug8.232014.9265@agate.berkeley.edu> from jerry@violet.berkeley.edu, Jerry Berkman writes: >According to the 1977 standard, pages 18-1 & 18-2, the symbolic >name of an external function is a global entity while the >symbolic name of an intrinsic function is a local entity. >And according to section 18.1.2: > > "a symbolic name that identifies a local entity may, > in a different program unit, identify an entity of > any class that is either local to that program unit > or global to the executable program." > >..., I expect the following program to print a 4 and a 2: [ Program deleted ...] >It does using 4.3 BSD f77 on a VAX or DEC's VMS FORTRAN compiler. >However IBM's VS FORTRAN and Cray's CFT77 issue a warning during >loading and then print a 2 followed by a 2! I.e. they do not >distinguish the intrinsic from the external! I ran his program on an AT&T 3B2/400, an AT&T 3B1 and an IBM PC/AT with the following results: MACHINE: AT&T 3B2/400 using FORTRAN 77 XLA+ OUTPUT: a 4 followed by a 4 -- OOPS seems to ignore the EXTERNAL MACHINES: AT&T 3B1 using SVS FORTRAN and IBM PC/AT using RM FORTRAN OUTPUT: a 4 followed by a 2 Summary: Of seven implementations, four gave the expected results, two ignored the intrinsic and one ignored the external index function. Jerry has just shown that not even STANDARD FORTRAN is portable! Unfortunately, many such examples can be documented. What happens to a standard after X3J3 has finished their work? Why isn't FORTRAN 77 more portable? A STANDARD CONFORMING FORTRAN compiler should NOT be released without first passing a suite of validation tests. Who should be responsible for the validation? Certainly not CBEMA! How about the NBS? Approved implementations ought to be dated and stamped with a registered trade-mark. Let me suggest that a cartoon of Magicicada septendecim be drawn and registered as the symbol of a validated FORTRAN implementation. ---------------------------------------------------------------------- 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) ----------------------------------------------------------------------
bam@bnlux0.bnl.gov (Bruce Martin) (08/16/89)
At end of item, poster suggests a "validation suite" for Fortran compilers. Aside from saying "Gee, that would be nice", I offer the following historical information. Actually, there is a "Fortran Automated Verification System (FAVS)", which is described in RADC (Rome Air Development Center) publication RADC-TR-78-268 (three small volumes, of which I could only find two, right now). I can't vouch for it, but it did receive much use in the early days of Fortran-77. Presumably, it is still available and useful, but DoD seems to have lost interest in performing validations for any languages whose names have four or more letters (or fewer than 2). The original Fortran Validation Suite was done by F. E. (Betty) Holberton of the National Bureau of Standards (now NIST). It consisted of an extensive set of programs to be run to determine if a processor conformed to X3.9-1966 (Fortran-66). Another related product was "PFORT", developed by Bell Labs (by Stu Feldman, I think) to determine whether a *program* conformed to the X3.9-1966 standard. Anyhow, a Fortran-88 validation suite would be nice, too, but I don't know who would write it, nor who would "certify" validations. Bruce A. Martin Grumman Aircraft Systems Mailstop B02-106 Bethpage, NY 11714 (516) 577-1426
khb@road.Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (08/16/89)
In article <603@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > >A STANDARD CONFORMING FORTRAN compiler should NOT be released >without first passing a suite of validation tests. Who should The majority of commerical fortran compilers do pass the FIPS ordained validation suite (FCVS). You can complain that it is not sufficiently well written to really ensure compliance with the standard, but you cannot reasonably claim that there are a dearth of validated compilers (nor that there isn't a validation process). Because FCVS is a FIPS this GSA certification is required for most government contracts, and folks who plan to do anything even faintly related to government work. Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
cdm@mhgya.att.com (45266-mclaughlin) (08/16/89)
Actually, the PFORT verifier was written by Andy Hall, not Stu Feldman. It grew out of a need to build a portable version of Altran (a language for manipulating symbolic algebraic expressions). It does not check for conformance to Fortran-66, but rather to a subset thereof that was empirically determined to be portable across a wide variety of compilers (fourteen, as I remember). As was pointed out in this group recently, there are no real guarantees that the existence of a standard and standard-conforming compilers will insure portability. There still may be ways to write non-portable, standard-conform- ing code. For that reason, the PFORT approach was to use the compiler itself as the definition of the language for any given machine and look for a common subset of compiler-accepted constructs that produced the same results on the class of machines of interest. So far as I know, no one has taken that approach to develop a comparable verifier for Fortran-77. C. D. (Dick) McLaughlin AT&T Bell Laboratories att!mhpo!cdm (UUCP) 600 Mountain Avenue - Room 2F-223 cdm@mhpo.att.com (INTERNET) Murray Hill, NJ 07974 attbl!c_d_mclaughlin (ATTMAIL)
mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) (08/16/89)
In message <2847...> cdm@mhgya.ATT.COM (45266-mclaughlin, charles d) writes: >.... For that reason, the PFORT approach was to use the compiler itself >as the definition of the language for any given machine and look for a common >subset of compiler-accepted constructs that produced the same results on the >class of machines of interest. So far as I know, no one has taken that >approach to develop a comparable verifier for Fortran-77. There is a FORTRAN-77 portability verifier in TOOLPACK that I have used to find a (distressingly) large number of unportable things in my codes. Unfortunately, TOOLPACK has trouble with even moderately large codes (my 7500 line code breaks it regularly). Splitting the code into sections works fine for some tests, but disables the interprocedural argument checking that I find the most useful test of the tool.... -- John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu mccalpin@delocn.udel.edu
bobal@microsoft.UUCP (Bob Allison) (08/18/89)
In article <603@mbph.UUCP> hybl@mbph.UUCP (Albert Hybl Dept of Biophysics SM) writes: > >Summary: Of seven implementations, four gave the expected results, >two ignored the intrinsic and one ignored the external index function. >Jerry has just shown that not even STANDARD FORTRAN is portable! >Unfortunately, many such examples can be documented. What happens to >a standard after X3J3 has finished their work? Why isn't FORTRAN 77 >more portable? > I don't understand the problem here: Jerry has clearly identified a program with well-defined functionality in terms of the standard and identified processors which are not standard-conforming in this area (although they may be validated compilers). >A STANDARD CONFORMING FORTRAN compiler should NOT be released >without first passing a suite of validation tests. Who should >be responsible for the validation? Certainly not CBEMA! >How about the NBS? Approved implementations ought to be dated >and stamped with a registered trade-mark. Let me suggest that >a cartoon of Magicicada septendecim be drawn and registered as >the symbol of a validated FORTRAN implementation. > Well, I'm glad to know we spend about $10,000 a year not doing anything (that's the cost to have NIST -- if the name hasn't changed again -- fly a guy out and run the validation tests). It seems to me you've warped this note string around to some entirely unrelated path. The real question is: what do you do once you find non-standard-conforming features in a validated compiler? I wish there was a way of calling NIST and complaining, and forcing the vendor to fix the defect before re-validating (the validation tests haven't changed in about four years). It would hold all of us to a higher level of accountability. >Albert Hybl, PhD. Office UUCP: uunet!mimsy!mbph!hybl Bob Allison PS. I tried it on our compiler and it worked fine. Thanks for the test case.