C H A P T E R 2 |
Using Fortran 95 |
This chapter describes how to use the Fortran 95 compiler.
The principal use of any compiler is to transform a program written in a procedural language like Fortran into a data file that is executable by the target computer hardware. As part of its job, the compiler may also automatically invoke a system linker to generate the executable file.
The Fortran 95 compiler can also be used to:
This section provides a quick overview of how to use the Fortran 95 compiler to compile and run Fortran programs. A full reference to command-line options appears in the next chapter.
The very basic steps to running a Fortran application involve using an editor to create a Fortran source file with a .f, .for, .f90, .f95, .F, .F90, or .F95 filename suffix; invoking the compiler to produce an executable; and finally, launching the program into execution by typing the name of the file:
Example: This program displays a message on the screen:
demo% cat greetings.f PROGRAM GREETINGS PRINT *, 'Real programmers write Fortran!' END demo% f95 greetings.f demo% a.out Real programmers write Fortran! demo% |
In this example, f95 compiles source file greetings.f and links the executable program onto the file, a.out, by default. To launch the program, the name of the executable file, a.out, is typed at the command prompt.
Traditionally, UNIX compilers write executable output to the default file called a.out. It can be awkward to have each compilation write to the same file. Moreover, if such a file already exists, it will be overwritten by the next run of the compiler. Instead, use the -o compiler option to explicitly specify the name of the executable output file:
In the preceding example, the -o option tells the compiler to write the executable code to the file greetings. (By convention, executable files usually are given the same name as the main source file, but without an extension.)
Alternatively, the default a.out file could be renamed via the mv command after each compilation. Either way, run the program by typing the name of the executable file at a shell prompt.
The next sections of this chapter discuss the conventions used by the f95 commands, compiler source line directives, and other issues concerning the use of these compiler. The next chapter describes the command-line syntax and all the options in detail.
The syntax of a simple compiler command invoked at a shell prompt is:
Here files... is one or more Fortran source file names ending in .f, .F, .f90, .f95, .F90, .F95, or .for; options is one or more of the compiler option flags. (Files with names ending in a .f90 or .f95 extension are "free-format" Fortran 95 source files recognized only by the f95 compiler.)
In the example below, f95 is used to compile two source files to produce an executable file named growth with runtime debugging enabled:
Note - You can invoke the Fortran 95 compiler with either the f95 or f90 command. |
New: The compiler will also accept source files with the extension .f03 or .F03. These are treated as equivalent to .f95 and .F95 and could be used as a way to indicate that a source file contains Fortran 2003 extensions.
Section 2.2.2, Command-Line File Name Conventions, describes the various source file extensions accepted by the compiler.
In the previous example, the compiler automatically generates the loader object files, growth.o and fft.o, and then invokes the system linker to create the executable program file growth.
After compilation, the object files, growth.o and fft.o, will remain. This convention permits easy relinking and recompilation of files.
If the compilation fails, you will receive a message for each error. No .o files are generated for those source files with errors, and no executable program file is written.
The suffix extension attached to file names appearing on the command-line determine how the compiler will process the file. File names with a suffix extension other than one of those listed below, or without an extension, are passed to the linker.
Fortran 95 free-format is described in Chapter 4.
The Fortran compiler will accept multiple source files on the command line. A single source file, also called a compilation unit, may contain any number of procedures (main program, subroutine, function, block data, module, and so on). Applications may be configured with one source code procedure per file, or by gathering procedures that work together into single files. The Fortran Programming Guide describes the advantages and disadvantages of these configurations.
f95 supports two source file preprocessors, fpp and cpp. Either can be invoked by the compiler to expand source code "macros" and symbolic definitions prior to compilation. The compiler will use fpp by default; the -xpp=cpp option changes the default from fpp to cpp. (See also the discussion of the -Dname option).
fpp is a Fortran-specific source preprocessor. See the fpp(1) man page and the fpp README for details. It is invoked by default on files with a .F, .F90, F95, or .F03 extension.
The source code for fpp is available from the Netlib web site at
http://www.netlib.org/fortran/
See cpp(1) for information on the standard Unix C language preprocessor. Use of fpp over cpp is recommended on Fortran source files.
You can compile and link in separate steps. The -c option compiles source files and generates .o object files, but does not create an executable. Without the -c option the compiler will invoke the linker. By splitting the compile and link steps in this manner, a complete recompilation is not needed just to fix one file, as shown in the following example:
Compile one file and link with others in separate steps:
demo% f95 -c file1.f (Make new object file) demo% f95 -o prgrm file1.o file2.o file3.o (Make executable file) |
Be sure that the link step lists all the object files needed to make the complete program. If any object files are missing from this step, the link will fail with undefined external reference errors (missing routines).
Ensuring a consistent choice of compiling and linking options is critical whenever compilation and linking are done in separate steps. Compiling any part of a program with some options requires linking with the same options. Also, a number of options require that all source files be compiled with that option, including the link step.
The option descriptions in Chapter 3 identify such options.
Example: Compiling sbr.f with -fast, compiling a C routine, and then linking in a separate step:
demo% f95 -c -fast sbr.f demo% cc -c -fast simm.c demo% f95 -fast sbr.o simm.o link step; passes -fast to the linker |
Any arguments on the command-line that the compiler does not recognize are interpreted as being possibly linker options, object program file names, or library names.
Note that in the first example, -bit is not recognized by f95 and the option is passed on to the linker (ld), who tries to interpret it. Because single letter ld options may be strung together, the linker sees -bit as -b -i -t, which are all legitimate ld options! This may (or may not) be what the user expects, or intended.
In the second example, the user intended to type the f95 option -fast but neglected the leading dash. The compiler again passes the argument to the linker which, in turn, interprets it as a file name.
These examples indicate that extreme care should be observed when composing compiler command lines!
f95 automatically creates module information files for each MODULE declaration encountered in the source files, and searches for modules referenced by a USE statement. For each module encountered (MODULE module_name), the compiler generates a corresponding file, module_name.mod, in the current directory. For example, f95 generates the module information file list.mod for the MODULE list unit found on file mysrc.f95 .
See the -Mpath and -moddir dirlist option flags for information on how to set the defaults paths for writing and searching for module information files.
See also the -use compiler option for implicitly invoking MODULE declarations in all compilation units.
Use the fdumpmod(1) command to display information about the contents of a .mod module information file.
For detailed information, see Section 4.9, Module Files.
Use a source code directive, a form of Fortran comment, to pass specific information to the compiler regarding special optimization or parallelization choices. Compiler directives are also sometimes called pragmas. The compiler recognize a set of general directives and parallelization directives. Fortran 95 also processes OpenMP shared memory multiprocessing directives.
Directives unique to f95 are described in Section 4.8, Directives. A complete summary of all the directives recognized by f95 appears in Appendix D.
The various forms of a general Fortran 95 directive are:
The variable keyword identifies the specific directive. Additional arguments or suboptions may also be allowed. (Some directives require the additional keyword SUN or SPARC, as shown above.)
A general directive has the following syntax:
Observe the following restrictions:
The Fortran compiler recognize the following general directives:
The C() directive specifies that its arguments are external functions. It is equivalent to an EXTERNAL declaration except that unlike ordinary external names, the Fortran compiler will not append an underscore to these argument names. See the C-Fortran Interface chapter in the Fortran Programming Guide for more details.
The C() directive for a particular function should appear before the first reference to that function in each subprogram that contains such a reference.
Example - compiling ABC and XYZ for C:
This directive causes the compiler to ignore the type, kind, and rank of the specified dummy argument names appearing in a generic procedure interface when resolving a specific call.
For example, in the procedure interface below, the directive specifies that SRC can be any data type, but LEN can be either KIND=4 or KIND=8.
The call to BLCKX will call BLCK_32 when compiled normally, and BLCK_64 when compiled with -xtypemap=integer:64. The actual type of S does not determine which routine to call. This greatly simplifies writing generic interfaces for wrappers that call specific library routines based on argument type, kind, or rank.
Note that dummy arguments for assumed-shape arrays, Fortran pointers, or allocatable arrays cannot be specified on the directive. If no names are specified, the directive applies to all dummy arguments to the procedure, except dummy arguments that are assumed-shape arrays, Fortran pointers, or allocatable arrays.
The UNROLL directive requires that you specify SUN after C$PRAGMA.
The C$PRAGMA SUN UNROLL=n directive instructs the compiler to unroll the following loop n times during its optimization pass. (The compiler will unroll a loop only when its analysis regards such unrolling as appropriate.)
n is a positive integer. The choices are:
If any loops are actually unrolled, the executable file becomes larger. For further information, see the Fortran Programming Guide chapter on performance and optimization.
Example - unrolling loops two times:
The WEAK directive defines a symbol to have less precedence than an earlier definition of the same symbol. This pragma is used mainly in sources files for building libraries. The linker does not produce an error message if it is unable to resolve a weak symbol.
WEAK (name1) defines name1 to be a weak symbol. The linker does not produce an error message if it does not find a definition for name1.
WEAK (name1=name2) defines name1 to be a weak symbol and an alias for name2.
If your program calls but does not define name1, the linker uses the definition from the library. However, if your program defines its own version of name1, then the program's definition is used and the weak global definition of name1 in the library is not used. If the program directly calls name2, the definition from library is used; a duplicate definition of name2 causes an error. See the Solaris Linker and Libraries Guide for more information.
The OPT directive requires that you specify SUN after C$PRAGMA.
The OPT directive sets the optimization level for a subprogram, overriding the level specified on the compilation command line. The directive must appear immediately before the target subprogram, and only applies to that subprogram. For example:
When the above is compiled with an f95 command that specifies -O4, the directive will override this level and compile the subroutine at -O2. Unless there is another directive following this routine, the next subprogram will be compiled at -O4.
The routine must also be compiled with the -xmaxopt[=n] option for the directive to be recognized. This compiler option specifies a maximum optimization value for PRAGMA OPT directives: if a PRAGMA OPT specifies an optimization level greater than the -xmaxopt level, the -xmaxopt level is used.
The NOMEMDEP directive requires that you specify SUN after C$PRAGMA.
This directive must appear immediately before a DO loop. It asserts to the optimizer that there are no memory-based dependencies within an iteration of the loop to inhibit parallelization. Requires -parallel or -explicitpar options.
The PIPELOOP=n directive requires that you specify SUN after C$PRAGMA.
This directive must appear immediately before a DO loop. n is a positive integer constant, or zero, and asserts to the optimizer a dependence between loop iterations. A value of zero indicates that the loop has no inter-iteration (loop-carried) dependencies and can be freely pipelined by the optimizer. A positive n value implies that the I-th iteration of the loop has a dependency on the (I-n)-th iteration, and can be pipelined at best for only n iterations at a time.
C We know that the value of K is such that there can be no C cross-iteration dependencies (E.g. K>N) C$PRAGMA SUN PIPELOOP=0 DO I=1,N A(I)=A(I+K) + D(I) B(I)=B(I) + A(I) END DO |
For more information on optimization, see the Fortran Programming Guide.
The -xprefetch option flag, Section , -xprefetch[=a[,a]], enables a set of PREFETCH directives that advise the compiler to generate prefetch instructions for the specified data element. Prefetch instructions are only available on UltraSPARC platforms.
C$PRAGMA SPARC_PREFETCH_READ_ONCE(name) C$PRAGMA SPARC_PREFETCH_READ_MANY(name) C$PRAGMA SPARC_PREFETCH_WRITE_ONCE(name) C$PRAGMA SPARC_PREFETCH_WRITE_MANY(name) |
See also the C User's Guide, or the SPARC Architecture Manual, Version 9 for further information about prefetch instructions.
The ASSUME directive gives the compiler hints about conditions at certain points in the program. These assertions can help the compiler to guide its optimization strategies. The programmer can also use these directives to check the validity of the program during execution. There are two formats for ASSUME.
The syntax of the "point assertion" ASSUME is
Alternatively, the "range assertion" ASSUME is:
Use the point assertion form to state a condition that the compiler can assume at that point in the program. Use the range assertion form to state a condition that holds over the enclosed range of statements. The BEGIN and END pairs in a range assertion must be properly nested.
The required expression is a boolean expression that can be evaluated at that point in the program that does not involve user-defined operators or function calls except for those listed below.
The optional probability value is a real number from 0.0 to 1.0, or an integer 0 or 1, giving the probability of the expression being true. A probability of 0.0 (or 0) means never true, and 1.0 (or 1) means always true. If not specified, the expression is considered to be true with a high probability, but not a certainty. An assertion with a probability other than exactly 0 or 1 is a non-certain assertion. Similarly, an assertion with a probability expressed exactly as 0 or 1 is a certain assertion.
For example, if the programmer knows that the length of a DO loop is always greater than 10,000, giving this hint to the compiler can enable it to produce better code. The following loop will generally run faster with the ASSUME pragma than without it.
C$PRAGMA BEGIN ASSUME(__tripcount().GE.10000,1) !! a big loop do i = j, n a(i) = a(j) + 1 end do C$PRAGMA END ASSUME |
Two intrinsic functions are available for use specifically in the expression clause of the ASSUME directive. (Note that their names are prefixed by two underscores.)
This list of special intrinsics might expand in future releases.
Use with the -xassume_control compiler option. (See Section , -xassume_control[=keywords]) For example, when compiled with -xassume_control=check, the example above would produce a warning if the trip count ever became less than 10,000.
Compiling with -xassume_control=retrospective will generate a summary report at program termination of the truth or falsity of all assertions. See the f95 man page for details on -xassume_control.
Compiling the above example with -xassume_control=check will issue a runtime warning should the loop not be taken because the trip count is zero or negative.
Parallelization directives explicitly request the compiler to attempt to parallelize the DO loop or the region of code that follows the directive. The syntax differs from general directives. Parallelization directives are only recognized when compilation options -openmp, -parallel, or -explicitpar are used. Details regarding Fortran parallelization can be found in the OpenMP API User's Guide and the Fortran Programming Guide.
The Fortran compiler supports the OpenMP shared memory parallelization model, as well as legacy Sun and Cray directives.
Parallelization features of the compiler are not available currently on x86 platforms.
The Fortran 95 compiler recognizes the OpenMP Fortran shared memory multiprocessing API as the preferred parallel programming model. The API is specified by the OpenMP Architecture Review Board (http://www.openmp.org).
You must compile with the command-line option -openmp, to enable OpenMP directives. (See Section , -openmp[={parallel|noopt|stubs|none}].)
For more information about the OpenMP directives accepted by f95, see the OpenMP API User's Guide.
Sun style parallelization directives are the default for -parallel and -explicitpar. Sun directives have the directive sentinel $PAR.
Cray style parallelization directives, enabled by the -mp=cray compiler option, have the sentinel MIC$. Interpretations of similar directives differ between Sun and Cray styles. See the chapter on parallelization in the Fortran Programming Guide for details. See also the OpenMP API User's Guide for guidelines on converting legacy Sun/Cray parallelization directives to OpenMP directives.
Sun/Cray parallelization directives have the following syntax:
TASKCOMMON, DOALL, DOSERIAL, and DOSERIAL*
Each parallelization directive has its own set of optional qualifiers that follow the keyword.
Example: Specifying a loop with a shared variable:
The Fortran 95 compiler provides an include file, system.inc, that defines the interfaces for most non-intrinsic library routines. Declare this include file to insure that functions you call and their arguments are properly typed, especially when default data types are changed with -xtypemap.
For example, the following may produce an arithmetic exception because function getpid() is not explicitly typed:
The getpid() routine returns an integer value but the compiler assumes it returns a real value if no explicit type is declared for the function. This value is further converted to integer, most likely producing a floating-point error.
To correct this you should explicitly type getuid() and functions like it that you call:
Problems like these can be diagnosed with the -Xlist (global program checking) option. The Fortran 95 include file `system.inc' provides explicit interface definitions for these routines.
Including system.inc in program units calling routines in the Fortran library will automatically define the interfaces for you, and help the compiler diagnose type mismatches. (See the Fortran Library Reference for more information.)
The next sections suggest a number of ways to use the Fortran 95 compiler efficiently. A complete compiler options reference follows in the next chapter.
Some compiler flags allow the user to tune code generation to a specific set of hardware platform options. The utility command fpversion displays the SPARC hardware platform specifications for the native processor:
The values printed depend on the load on the system at the moment fpversion is called.
See fpversion(1) and the Numerical Computation Guide for details. fpversion is not available on x86 platforms.
You can specify options by setting the FFLAGS or OPTIONS variables.
Either FFLAGS or OPTIONS can be used explicitly in the command line. When you are using the implicit compilation rules of make, FFLAGS is used automatically by the make program.
Example: Set FFLAGS: (C Shell)
Example: Use FFLAGS explicitly:
When using make, if the FFLAGS variable is set as above and the makefile's compilation rules are implicit, that is, there is no explicit compiler command line, then invoking make will result in a compilation equivalent to:
make is a very powerful program development tool that can easily be used with all Sun compilers. See the make(1) man page and the Program Development chapter in the Fortran Programming Guide.
A compilation may need to use a lot of memory. This will depend on the optimization level chosen and the size and complexity of the files being compiled. On SPARC platforms, if the optimizer runs out of memory, it tries to recover by retrying the current procedure at a lower level of optimization and resumes subsequent routines at the original level specified in the -On option on the command line.
A processor running the compiler should have at least 64 megabytes of memory; 256 megabytes are recommended. Enough swap space should also be allocated. 200 megabytes is the minimum; 300 megabytes is recommended.
Memory usage depends on the size of each procedure, the level of optimization, the limits set for virtual memory, the size of the disk swap file, and various other parameters.
Compiling a single source file containing many routines could cause the compiler to run out of memory or swap space.
If the compiler runs out of memory, try reducing the level of optimization, or split multiple-routine source files into files with one routine per file, using fsplit(1).
The command, swap -s, displays available swap space. See swap(1M).
Example: Use the swap command:
To determine the actual real memory:
Use mkfile(1M) and swap(1M) to increase the size of the swap space on a workstation. You must become superuser to do this. mkfile creates a file of a specific size, and swap -a adds the file to the system swap space:
demo# mkfile -v 90m /home/swapfile /home/swapfile 94317840 bytes demo# /usr/sbin/swap -a /home/swapfile |
Compiling very large routines (thousands of lines of code in a single procedure) at optimization level -O3 or higher may require additional memory that could degrade compile-time performance. You can control this by limiting the amount of virtual memory available to a single process.
In a sh shell, use the ulimit command. See sh(1).
Example: Limit virtual memory to 16 Mbytes:
In a csh shell, use the limit command. See csh(1).
Example: Limit virtual memory to 16 Mbytes:
Each of these command lines causes the optimizer to try to recover at 16 Mbytes of data space.
This limit cannot be greater than the system's total available swap space and, in practice, must be small enough to permit normal use of the system while a large compilation is in progress. Be sure that no compilation consumes more than half the space.
Example: With 32 Mbytes of swap space, use the following commands:
The best setting depends on the degree of optimization requested and the amount of real and virtual memory available.
In 64-bit Solaris environments, the soft limit for the size of an application data segment is 2 Gbytes. If your application needs to allocate more space, use the shell's limit or ulimit command to remove the limit.
See the Solaris 64-bit Developer's Guide for more information.
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.