Complying with Fortran 90
How does the current crop of Fortran 90 compilers measure up to the standard?
Steven Baker
Steven works for the Oregon Department of Energy coaxing energy conservation out of new state buildings. He is the "Networking" columnist for Unix Review, former editor of Programmer's Journal, and co-author of Extending DOS. Steven can be reached at [email protected].
Originally written at IBM in the 1950s, FORTRAN is by computer standards an ancient language. Like its sibling COBOL, however, FORTRAN remains an important software-development tool. One obvious reason is that a huge amount of software in use today was written in FORTRAN. This code base also includes some very substantial programming libraries that are fast, fully tested, and debugged.
FORTRAN is also fast at number crunching. While Pascal, C, and more recently C++ have displaced earlier-generation languages for general-purpose applications, numerics remains the realm of FORTRAN. Compared with C and C++, FORTRAN supports a native complex data type along with a rich set of intrinsic math functions that are easily inlined for fast execution speed. FORTRAN lacks the loose variable aliasing of C and C++ pointers, so FORTRAN compilers can better optimize code. With Fortran 90--the most recent version of the FORTRAN standard--array syntax has been added to the language, allowing you to manipulate arrays as simply as any other variable type. FORTRAN compiler vendors are free to speed array operations by inlining or making calls to optimized library routines. While C++ can offer some of these benefits with suitable math class libraries (Rogue Wave's LAPACK++ and Dyad Software's M++ come to mind), execution speed inevitably favors FORTRAN. When you are executing a simulation that may take hours or days, differences in run time become a major consideration.
While the previous FORTRAN standards (FORTRAN-66 and FORTRAN-77) dealt primarily with codifying existing practice, Fortran 90 breaks new ground by extending the FORTRAN language, adding features found in other modern computer dialects (pointers, modules, interface blocks, and user-defined data types equivalent to C's structures, for example) along with some special facilities of its own for handling numerical accuracy. Because of this richness, the Fortran 90 language is large and complex. Although Fortran 90 was adopted in 1991, it has taken time for compiler and tool vendors to comply with the standard. The first wave of Fortran 90 tools were translators that converted from Fortran 90 to an intermediate language (FORTRAN-77 or C) for compilation. Traditional FORTRAN vendors are now releasing Fortran 90 tools based both on these existing translators and on native compilers; see Table 1.
Lingua Fortrana
With the arrival of Fortran 90 tools, it is timely to consider compliance with the Fortran 90 standard. Using tools that comply with standards can have obvious benefits, the least of which is portability between different computer environments. Checking for compliance can have other positive effects, including hastening improvements in tools, exposing gray areas in the standard, and identifying problems to be addressed in future work.
Historically, compliance with computer standards has been handled by the adoption of official test suites by government agencies. In the U.S., the National Institute of Standards and Technology (NIST) administers test suites for compliance with FORTRAN-77, COBOL, Pascal, Ada, SQL, and the like. NIST publishes a quarterly report, the Validated Processor List, listing those vendor products which have passed and are currently in compliance. NIST has yet to develop a procedure for validating Fortran 90 compilers.
Compiler vendors inevitably need test suites for quality assurance and testing to support their own development efforts. In the case of Fortran 90, this meant that the first Fortran 90 vendors were also forced to develop test suites as part of the process of tool development. Based on its early entry and experience in the FORTRAN market, the Numerical Algorithms Group (NAG) has been successful in selling its test suite to many other vendors. Other test suites have been developed by Lahey, Parasoft, and Cray--FORTRAN vendors on PC, UNIX, and supercomputers, respectively. SHAPE, a special suite for testing the array-processing areas of Fortran 90, was developed by Spackman and Hendrickson (two members active in the Fortran 90 standards process).
The companies in Table 2 were gracious enough to provide me copies of their respective test suites as long as I reported the results in general categories, not as specific test results. Since each test suite was developed initially with a particular Fortran 90 compiler or translator, these test suites all have a bias toward a particular product.
Aside from these specific test suites, FORTRAN tool vendors often gather collections of test code from customers to use for regression testing before release of a new product or version. An advantage of such miscellaneous test code is that it is authored by many programmers, typically with very different coding styles. While test suites may contain a few thousand trivial 40-line programs, "real" FORTRAN code is often more likely to stress the FORTRAN compilers and discover problems. Basing testing on such code is difficult because the user may not have any idea what the code does or how to properly prepare input and check output, and may not have the time and patience to hand review the code for standards compliance.
Compliance and Conformance
Before reviewing the specific test results, let's first examine what the Fortran 90 standard specifies about compliance. The standard distinguishes between the compiler/translator and a Fortran 90 program. A "processor" is defined as "the combination of a computing system and the mechanism by which programs are transformed for use on the computing system." For conformance, the standard specifies the requirements, prohibitions, and options for permissible forms and relationships in a program rather than in a processor. Any requirements for a compiler or translator (a "processor" in standards jargon) must be inferred from those given for a conforming program. Realistically, the only reasonable way to test for a conforming program is to compile the test program with a processor that complains when the Fortran 90 standard requirements are not met (a Fortran 90 catch-22).
Table 3 lists the general conditions that must be met by a conforming processor. Although no deleted features were included in the standard, a number of features were marked as obsolescent; see Table 4. For the first time, this allows features (often relics of ancient FORTRAN practices) to be removed from subsequent FORTRAN standards. At current rates, however, this won't be until the next century.
A few additional caveats free the processor from meeting the aforementioned requirements in format specifications that are not part of a FORMAT statement. This particular exception reflects the practice of passing a format specifier as a character variable, forcing format parsing and interpretation to occur only during run time rather than during compilation. In this regard, FORTRAN's formatted I/O is similar to the C stdio library, which also requires interpretation at run time.
A Fortran 90 compiler is free to support other language extensions as long as they don't conflict with the standard. For example, Fortran 90 limits variables to 31-character names. Several FORTRAN compilers offer longer variable names as an extension, but a conforming Fortran 90 program must comply fully with the standard and not use any extensions.
While Fortran 90 was designed to be backward compatible with FORTRAN-77, interpretations differ in five cases. The standard also excludes certain processor-dependent issues, including the physical representation of numbers, rounding, input/output records and files, and storage.
The Fortran 90 standard document spells out in gory detail the various requirements, prohibitions, and options that must be met. A number of prohibitions are specifically highlighted as "constraints" in the document. For example, section 3.3.2 explicitly states: "Constraint: The maximum length of a name is 31 characters."
However many of the requirements are implicit in the document and must be inferred by the reader from the text. For example, the syntax rules require a name to begin with one of the 26 alphabetic letters and may consist of these letters, the ten digits, and the underscore (_) character. An implied requirement would be the prohibition of names beginning with a digit. A test case might try the following code fragment:
PROGRAM 123TEST PRINT *, 'Fail' END
Creating test cases for the explicit constraints is reasonably straightforward: Devise at least one test for each official constraint in the standard document. Although this may be time consuming, the procedure is reasonably well defined. In contrast, the process of testing for other rules and implied requirements is much more challenging. The document must be painstakingly scoured for these implicit restrictions.
A Bumper Crop of Compilers
To gauge the current state of Fortran 90, I worked with most of the available Fortran 90 compilers, translators, and test suites; see Tables 1 and 2. The Apogee, Parasoft, and Pacific-Sierra Research (PSR) tools translate from Fortran 90 to FORTRAN-77 and then invoke a native FORTRAN-77 compiler. VAST-90 from PSR is much more than a simple translator since it contains a powerful vectorizer and facilities to translate from FORTRAN-77 to Fortran 90. Parasoft f90 also translates CM Fortran (Thinking Machines) to FORTRAN-77 and has been widely used by the High Performance Fortran (HPF) community. NAGWare f90 translates Fortran 90 to C and then invokes a native C compiler. The Apogee compiler uses technology from Kuck and Associates for translation to FORTRAN-77 using its native Apogee Fortran compiler for SPARC as a back end. Microway's NDP compiler uses technology from PSR with its existing FORTRAN compiler as a back end. The remaining vendors--CraySoft, Digital, EPC, Fujitsu, IBM, and Lahey--have true Fortran 90 compilers.
The products based on translators come with a driver program and libraries that automate the process of translating Fortran 90 code and compiling the resulting files. You must supply a suitable FORTRAN-77 or C compiler with the Parasoft, PSR, and NAG products. These three translators are offered on various UNIX workstations (Sun, HP, IBM, and so on) and have been around for some time. EPC Fortran 90 was first introduced in the summer of 1993. The others are relatively new, having been released in 1994.
I tested these tools on a variety of platforms, including a Sun SPARCstation 2+ and a SPARCserver 1000 running Solaris 2.3, an IBM RS/6000 Model 250 (PowerPC) running AIX 3.2.5, and a DEC Alpha AXP Model 3000-50 running OSF/1 3.0. The SunPro Fortran 3.0 and C compilers were used as back ends with the translators from NAG, PSR, and Parasoft. The IBM and Digital Fortran compilers were used as back ends for the translators on their respective platforms.
Problems Being Portable
Writing a good test suite is a daunting task. For completeness, this necessitates poring through dense standard documents and culling out the requirements, prohibitions, and other options that must be met. Then the actual test cases must be written and debugged to verify proper or erroneous behavior. For automating the process, some sort of driver program or scripts must be written that compile the test cases, compare the results against expected behavior, and report the outcome in a usable format. The difficulty is exacerbated since the motivation for most of these tests (with the exception of SHAPE) was in support of Fortran 90 compiler development, not an end unto itself. As long as the test suite worked well with the compiler under development, it was deemed satisfactory. My own experiences with multiple Fortran 90 compilers taxed all of the test suites and found significant problems.
There can be basic problems with the ways individual tests are written. In the four general-purpose suites, the largest share of test cases checks for invalid constructs with negative tests that are expected to fail at compile time. But the test code might fail for an improper reason, or a compiler might support some Fortran 90 extensions that allow it to pass. In order to be certain with negative tests, the compile results need to be saved and hand-reviewed for appropriate behavior--a very time-consuming task. One attraction of the NAG test suite is that it is relatively easy to set up initially. But it does a poor job on negative tests. As long as the compile failed, it considers the test to have passed. The test scripts don't even save the compiler output messages for review.
The alternative is to customize negative tests to anticipate specific error messages from the compiler. This provides the greatest amount of reliability, but at a cost. With customized checks, the test suite for a single compiler can take weeks to set up. If compiler error messages are changed, these customized checks will need to be modified. CraySoft, the Cray test suite is the worst in this regard, since it tests for matches with specific error messages that indicate the source line that failed. Lahey's test suite allows for this behavior in a more flexible way, using custom compiler-specific blocks in an information file (.inf) for each test. But the Lahey test driver also supports a default behavior if an info file is not specified, as well as a default block in a test-specific info file. The Parasoft scripts test for exact matches for the translation from Fortran 90 to FORTRAN-77 fed to the native FORTRAN compiler and the run-time output. Fortunately, in the Parasoft case, scripts are provided to generate the custom check files, assuming that the translator output is correct--a major assumption.
Most of the positive tests in all the suites suffer from using list-directed I/O (print *, i, r, a(10)). The Fortran 90 standard allows complete latitude by the compiler writer on the format produced with such print statements. Any number of blanks may be inserted before the actual number or string, the number of decimal digits displayed for a number is compiler dependent, and the number of variables displayed on a single line (the assumed line length) can all vary. Thus, creating output files for checking becomes completely compiler dependent and consequently, time consuming.
The SHAPE tests are better since they check the results internally against known quantities. The NAG test suite tries to handle this with a general-purpose "check" module linked into many of the tests that handles this comparison after blanks and commas are stripped. Unfortunately, the test cases and the check module were written in a manner that assumes certain behavior, making them compiler dependent. Only after rewriting a large number of test cases did the NAG tests become portable. Lahey requires that custom output files be created along with modifying the test info file for each test case if the output from a compiler does not match the Lahey-supplied comparison files. This is a tedious process and forced me to limit my use to only portions of the Lahey test suite. On the other hand, the Lahey test driver does by far the best job of saving all the input and output files from a test for later review.
Another issue is how the entire test suite or portions are invoked and the results saved for later perusal. The ideal would be an automated scheme that allowed running all or only portions of a test and created simple yet comprehensive report files. SHAPE takes the simplest scheme and doesn't provide an automatic method to run all the test cases. Since it consists of only 26 files, it would be time-consuming but manageable to execute 26 test compiles followed by test runs by hand (I wrote my own shell scripts).
The Lahey test suite comes with source code to a sophisticated driver program written in C to manage the entire process, saving the results on failures completely. The other test suites use a series of UNIX shell scripts to invoke the tests. NAG uses a complex set of nested shell scripts spread over a dozen different test directories. The Cray test suite requires GNU awk (gawk) for its shell scripts but doesn't supply source or binaries to this freely available utility. I spent considerable time removing bugs from the Lahey driver program and cleaning up and revising the nested shell scripts from NAG. For use with DOS, I benefitted from the DOS version of the MKS Toolkit (from Mortice Kerns Systems, Waterloo, ON) with its Korn shell and UNIX-like utilities that allowed me to rewrite the NAG and CraySoft shell scripts.
Finally, the individual test cases may include code that does not meet the Fortran 90 standard or assumes certain behavior by the compiler. For example, a number of the NAG test cases had embedded KIND numbers specific to the NAG translator. Only after these were removed did the test cases became portable. SHAPE assumed that preconnected units were supported and issued READ and WRITE statements without prior OPEN or INQUIRE statements.
The bottom line is that results from these validation suites should be taken with a grain of salt. These tests consist mostly of very short, narrowly focused bits of code that might well not stress a FORTRAN compiler as much as a sizable "real" program. I, for instance, learned more from trying to get NAG's rather complex check module to compile than from running many of the tests.
Since many of the UNIX vendors (DEC, EPC, Fujitsu, IBM, PSR, and of course NAG) have licensed the NAG test suite, you'd expect a high degree of compliance with the NAG tests. However, testing these tools with a different test code may reveal some problems that NAG misses. The SHAPE array tests were a good case in point.
Picking Test Cases
Setting up and using a test suite can require an enormous amount of work. The time this takes is related to how well the driver program and test cases were written in the first place. One benefit of configuring and running a test suite is the considerable education you receive on the Fortran 90 language during the process.
For the results presented here, I selected what I consider the better parts of several test suites. The NAG suite is most rigorous when testing for operations with different KIND numbers. Fortran 90 data types can be declared with a KIND number to support greater or less range in a portable manner. However, the standard does not specify what these KIND numbers (integer values) should be; see Table 5. Intrinsic functions will return the appropriate KIND value for integer and real data types based on the range and precision desired. NAG uses a compiler.f90 module that must be customized with appropriate KIND values and I/O constants for each compiler. NAG uses template files to generate test programs with these compiler-specific values for testing array handling, keywords, and I/O. The actual number of test cases generated depends on the KIND numbers supported by a compiler. The Cray tests have a similar facility requiring the creation of a configuration file for each compiler.
The NAG suite includes a large number of invalid-constraint tests along with separate tests for detecting obsolete features. NAG also includes a very rigorous test using keywords as a variable in almost any possible situation. While using keywords as variables isn't the best practice, this was the only test suite to address this issue comprehensively.
SHAPE is very strong on array handling, the sole focus of its tests. Lahey's LTEST contains a sizable number of test cases for invalid and implied constraints. Lahey also has separate directories to test some of the intrinsic functions (over 70) required by Fortran 90 and memory-allocation routines. Only the CraySoft test suite had separate tests for interpretations issued since the Fortran 90 document was published. These tests gauge whether a tool is keeping abreast of changes. Not surprisingly, the CraySoft tests were strong on array syntax, given their supercomputing heritage. I would have used more of the Lahey, CraySoft, and Parasoft tests except that the time to write the necessary customized output files for comparisons was too demanding.
Comparing Compilers
Table 6 presents the results of the selected tests for these Fortran 90 processors. The new native UNIX compilers do quite a good job of complying with the standard. NAG was responsible for a major test suite, hence its high level of compliance. On the other hand, some of the products based on translators still have a considerable way to go.
Several translator-based products (Apogee, Microway, and Parasoft) suffered in the NAG suite because many of the test cases depend on a complex check module linked in with each test. If the translator had difficulty with this one module, then unfortunately all the tests failed. Although Microway uses technology licensed from PSR, the translator component is an earlier version than that currently in PSR's Vast90. This accounts for the difference in compliance between Microway and PSR. When Microway merges in the latest PSR updates, compliance results should be similar. I should stress that both the Apogee and Fujitsu products were still in beta and will undoubtedly improve before commercial release.
The compliance results based on LTEST were generally lower than the equivalent NAG test outcomes. This likely reflects the fact that many of the vendors use NAG for regression testing. The Lahey and NAG suites also weigh tests differently, emphasizing a particular constraint or rule in separate test cases.
The number of failed constraint tests should be viewed with caution. For example, the NAG suite includes 66 separate test cases that use variable names longer than the Fortran 90 standard of 31 characters. If a compiler does not fail these tests and omits reporting these as Fortran 90 extensions, this will account for 3 percent of the failures. Similar numbers of repeated tests exist for other common extensions (binary and hexadecimal constants, for example). All constraint tests are weighted equally. Yet many of these tests are nitpicking and don't affect real programs. For example, the standard specifies that only a single PRIVATE or SEQUENCE keyword may appear in a derived type. Extra (extraneous) PRIVATEs will likely have no effect on your current programming efforts.
Surprisingly, the Cray, Fujitsu, and Microway FORTRAN compilers failed to recognize and report the obsolete features as required by the FORTRAN standard.
While for most tests the DEC compiler exhibited a high degree of compliance, it failed a substantial number of keyword tests. A minor change to the NAG test suite found an internal error in the compiler that accounts for most of these failures. The SHAPE test suite was more problematic for many of the products. Consisting of 22 source files varying in size from 20K to 1.5 Mbytes, each file contains from a dozen to 800 test cases. If a file failed to compile, I was forced to note all the results as failures.
Fortran 90 provides for the use of interface blocks to document how parameters to a subroutine or function are to be used. The intent of parameter use can be designated as IN (input only), OUT (output only), or INOUT (both). Aside from its documentation value, this feature can be very useful in catching bugs such as using a variable before it is initialized. Although not required by the standard, PSR's Vast90 was the only product that flagged incorrect interface blocks. The Fujitsu compiler supports a useful run-time option to check for proper subroutine and function parameter types at run time. This found one of the subtle bugs in the NAG check module.
Along with the NAG translator, UNIX compilers from EPC, IBM, and Fujitsu lead the pack. If I had to choose an official winner, it would probably be EPC. Under DOS, the Lahey compiler exhibited a much higher level of compliance than Microway.
An obvious concern is the quality of code produced and the effect of optimization on language compliance. All of the test results in Table 6 were based on executing the compilers with optimization disabled. As a simple test, I also reran the NAG suite using the IBM compiler with default optimizations enabled (--O switch). Language compliance was reduced by about 5 percent.
Other Considerations
Of course, official language compliance isn't everything. Most of these tools also support a range of extensions to allow easy use with older FORTRAN. The Digital and IBM tools are designed to swallow older FORTRAN written to their earlier mainframe and minicomputer compilers. The IBM XL compiler also supports Cray, VAX, and Sun extensions. EPC and Lahey also support a number of VAX FORTRAN extensions. Apogee and Fujitsu offer language support for a number of Sun FORTRAN extensions. Parasoft and PSR support CM Fortran (Thinking Machines) extensions commonly used by the high-performance FORTRAN community. DEC supports the HPF extensions (FORALL, for example) and offers options for its Parallel Software Environment.
There are other considerations aside from language compliance. For many FORTRAN users, this may equate with the execution speed of the code generated or the ease of use. Several of these products (EPC, Lahey, and Microway) come bundled with debuggers designed to support Fortran 90. Apogee includes a version of the GNU gdb debugger that has been modified to support FORTRAN-77 syntax. Fujitsu offers its compiler separately and also bundles it with a Fortran 90 workbench environment supporting source-code editing and debugging. DEC and IBM offer a separate workbench with which their Fortran 90 products may be integrated. The DEC FUSE workbench currently lacks full support for Fortran 90. The IBM Fortran POWERbench is an integrated GUI environment for UNIX that fully supports the Fortran 90 language. The translators from NAG, PSR, and Parasoft make debugging more difficult since the user is dealing with translated code rather than with the original Fortran 90 source. NAG provides some limited guidance in its manual to assist debugging the translated C code.
Of primary consideration is the quality of the code generated and the speed of execution. Comparing the translators, the Apogee, Parasoft, and PSR products that use FORTRAN-77 as an intermediate language produce noticeably faster code than the NAG C translations. Much of this is likely inherent in the difference between C and FORTRAN for numerics. Contrary to common assumptions, native Fortran 90 compilers don't necessarily produce the fastest code. Because PSR's Vast90 and Apogee's Fortran 90 include sophisticated vectorizers, their code can often outperform that of native compilers. Using Vast90, this was the case across all of the platforms tested (Sun, IBM, and DEC). IBM even offers a special version of the PSR vectorizer (VAST2) at additional cost for regular IBM FORTRAN users. The DEC compiler currently creates scalar code and lacks the ability to generate faster vectorized output for the DEC Alpha.
Back to the Future
Fortran 90 holds a lot of promise as a means to modernize the FORTRAN language and FORTRAN user community. The ideal development environment would offer full compliance with the Fortran 90 standard and yet support all of the old FORTRAN code still being used today. Fortunately, many of the compilers are approaching this goal. For some of the translator-based tools, complying with the Fortran 90 standard remains a challenge. Compared with their UNIX counterparts, the DOS compilers offer poor language compliance. While it has taken longer than expected, programmers now have a healthy range of choices for quality Fortran 90 development tools. Based on these tools and those still to come, FORTRAN as a language may well be around for another half a century.
For More Information
Apogee-Fortran 90
Apogee Software
1901 South Bascom Avenue Suite 325
Campbell, CA 95008-2207
800-854-6705, 408-369-9010
CraySoft Fortran 90 SPARC
Cray Research Inc.
1440 Northland Drive
Mendota Heights, MN 55120
800-289-2729, 612-683-3030
DEC Fortran 90
DEC
146 Main Street
Maynard, MA 01754
800-332-7923
EPC Fortran 90
Edinburgh Portable Compilers
20 Victor Square
Scotts Valley, CA 95066
800-EPC-1110, 408-438-1851
Fujitsu Fortran 90
Fujitsu Open Systems Solutions
3055 Orchard Drive
San Jose, CA 95134
800-545-6774, 408-456-7853
AIX XL Fortran Compiler/6000
IBM
1133 Westchester Avenue
White Plains, NY 10604
800-426-2255, 914-642-3000
LTEST Test Suite for Fortran 90
Lahey Fortran 90
Lahey Computer Systems
865 Tahoe Boulevard
Incline Village, NV 89450
800-548-4778, 702-831-2500
NDP Fortran 90
Microway
P.O. Box 79, Research Park
Kingston, MA 02364
508-746-7341
NAG Fortran 90 Test Suite
NAGWare f90
Numerical Algorithms Group
1400 Opus Place, Suite 200
Downers Grove, IL 60515-5702
708-971-2337
Portable Fortran 90
ParaSoft
2031 South Myrtle Avenue
Monrovia, CA 91016
818-305-0041
SHAPE Test Suite
Spackman & Hendrickson
13708 Krestwood Drive
Burnsville, MN 55337
612-892-5847
VAST-90
Pacific-Sierra Research
2901 28th Street
Santa Monica, CA 90405
310-314-2300
Table 1: Fortran 90 compilers/translators tested.
Tool Version Vendor Available Platform(s)
Apogee Fortran 90 3.0 Apogee Solaris 2 (SPARC), SunOS
CraySoft Fortran 90 1.0 Cray Solaris 2 (SPARC)
DEC Fortran 90 1.1 Digital DEC OSF/1 (Alpha)
Fortran 90 1.1.2 EPC RS/6000, SGI (Mips 3000/4000),
Solaris 2 (SPARC), SunOS
Fortran 90 2.0beta Fujitsu Solaris 2 (SPARC)
XL Fortran 1.1 IBM AIX (RS/6000)
Lahey Fortran 90 1.00D Lahey DOS (on 386, 486, or Pentium)
NDP Fortran 90 4.5 Microway DOS (on 386, 486, or Pentium)
NAGWare f90 2.0b NAG HP-UX, RS/6000, SCO, SGI, Solaris
2 (SPARC), SunOS
Portable Fortran 90 2.0 Parasoft Convex, HP-UX, IBM 3090, RS/6000, SGI,
Solaris 2 (SPARC), SunOS
Vast90 2.6 PSR HP-UX, RS/6000, Solaris 2
(SPARC), SunOS
Table 2: Fortran 90 test suites.
Tool Vendor Cray Fortran 90 Test Suite CraySoft LTEST Lahey NAG Fortran 90 Test Suite Numerical Algorithms Group (NAG) Parasoft Fortran Test Suite Parasoft SHAPE Spackman & Hendrickson
Table 3: General Fortran 90 requirements. (The term "detect" represents the phrase "can detect and report" in the standard.)
- Execute any standard-conforming program consistent with the standard (with caveats on program size and complexity).
- Detect the use of deleted or obsolescent features.
- Detect the use of code not permitted by the Fortran 90 syntax rules.
- Detect the use of kind type parameter values not supported by the processor.
- Detect the use of source form or characters not permitted.
- Detect name usage not consistent with Fortran 90 scope rules for names, labels, operators, and assignment symbols.
Table 4: Fortran 90 obsolescent features.
Alternate return Arithmetic IF ASSIGN and assigned GOTO statements Assigned FORMAT specifiers Branching to an ENDIF statement from outside the IF block H edit descriptors PAUSE statement Real and double precision DO loop variables Shared DO termination on a statement other than ENDDO or CONTINUE
Table 5 Fortran 90 KIND numbers. (All tools support a single Character KIND of 1, with Fujitsu compiler adding a KIND number of 2 for Japanese characters.) Table 6 Fortran 90 compliance results.
Copyright © 1995, Dr. Dobb's Journal
