The object files that are linked come from one of these sources:

A DSO is normally stored in a file with the suffix .so. The building of DSOs is described under “Creating Dynamic Shared Objects”.

Archives are collections of object files in a single file, normally given a suffix of .a. The use of the archive-builder ar is covered in the MIPS Compiling and Performance Tuning Guide.

Any kind of object file—compiled .o, DSO .so, or archive .ar—can be specified as an input file on the f90 command line.

You specify the name of a library indirectly, using the -L and -l driver options. The compiler adds the prefix lib to the name specified with -l, and searches for libname.so or libname.a in the directories where libraries are kept. For example, if you specify -lblas, the driver searches for a file libblas.so or libblas.a. If you specify -L/usr/f90/objects, the driver searches that directory when looking for library files.

The end result is that the library (which is simply a DSO or archive file) is included in the link phase of the compile. You can achieve the same result by giving the full name of the library as an input to f90.

The driver searches for libraries first in directories named by the -L option, and then in /usr/lib64 and in /usr/lib64/mips4t.

The driver includes certain libraries by default:

Some libraries that are often included using the -l option are libfpe for floating-point exceptions, libfGL, the Fortran bindings to Open GL, and libblas, the BLAS math procedures.

When the object code of a procedure is included as part of the executable file, it is statically linked; that is, the connection between the call and the entry point is permanently fixed in the executable file. Procedures defined in object files and archive files are always statically linked.

When the object code of a procedure is found in a DSO, the procedure is dynamically linked; that is, only the names of the procedure and the DSO are included in the executable program file. When the executable program is loaded, the DSO is also loaded, and the linkage between the call and the procedure is resolved at that time.

Most run-time libraries distributed with Fortran 90 are in DSO form, so the Fortran run-time support code and intrinsic procedures are dynamically linked.

A large program is normally divided into many source files, each compiled separately. These files may all be written in Fortran 90; or some of them may be written in a different language—Fortran 77 or C, for example.

Exactly one of these files must be a main module. In Fortran 90 or Fortran 77, a main program is one that contains a PROGRAM statement. In C or C++, a main module contains a main() function definition.

To compile and link a multiple-file program, first compile each file using the -o driver option to produce an object file for that source file. Then compile all the .o files, using the driver for the language of the main module. (Any of the MIPSpro compiler drivers can perform the link step for any combination of object files.)

For example, imagine a program consisting of these files:

This program could be compiled into an executable named master using the commands shown in Example 1-1.

f90 -O3 -64 -c master.f90
f77 -O3 -64 -c procs.f
cc -O3 -64 -c funcs.c
f90 -o master master.o procs.o funcs.o

You perform the final step using the language for the main program because that driver includes the appropriate program-setup procedure and library code by default.

The concepts and use of dynamic shared objects (DSOs) are covered in the MIPS Compiling and Performance Tuning Guide, and in the dso(5) and rld(1) reference pages. For example, the MIPS Compiling and Performance Tuning Guide covers details of how different versions of DSOs are created and used.

You can create a DSO based on one or more Fortran 90 source files, provided that they are not main program files. Then other Fortran 90 programs can link dynamically to the procedures in that DSO.

---

Note: The concept of a DSO and the concept of a Fortran 90 MODULE are quite distinct and should not be confused. You can link the object files from one or more MODULEs to form a DSO. This is a good method of packaging the object code of MODULEs. However, the compiler does not do this by default. A source file that defines one or more MODULEs is compiled to a single object file. You can statically link this file with other object files that need it, or you can link it to form a DSO.

---

The source of a small MODULE is displayed in Example B-12. Suppose this source is stored in a file dgrtrig.f90. It can be converted into a DSO using the commands shown in Example 1-2.

f90 -O3 -64 -c dgrtrig.f90
ld -shared -64 dgrtrig.o -o dgrtrig.so

The compilation step produces the object file dgrtrig.o, which could be statically linked with any other program. (The compilation also produces a file DEGREE_TRIG.kmo, containing a summary of the module; this file is used to compile a USE DEGREE_TRIG statement that appears in any later compile.) The ld command in Example 1-2 produces the DSO, dgrtrig.so.

When a program uses a procedure that is defined in a DSO, you must take two steps.

Linking a DSO as an Object File

You can simply name the DSO as an input file on the driver command line. The short program in Example 1-3 uses the module that is converted to a DSO in Example 1-2.

Example 1-3. Program That Uses a Module

use degree_trig print *,"sin",dgr,dsind(45.0_8) end

Suppose that the DSO dgrtrig.so is in the current directory. Then the program in Example 1-3 could be compiled as follows:

f90 -g -64 -o usedgr usedgr.f90 dgrtrig.so

While compiling the program, the compiler reads DEGREE_TRIG.kmo to learn the public names in the module. While linking the program, the linker resolves external references using entry point information in dgrtrig.so, but does not include the DSO contents in the executable file.

---

Tip: If you specify the full path to a DSO when linking, the path is recorded in the executable file and the loader does not need to search for the DSO when loading the program.

---

f90 -g -64 -L/usr/local/f90/objects \
        -ldgr -o usedgr usedgr.f90

When you are compiling a program that does not have high performance requirements, you need only a very few compiler options. Examples of such programs include

In these cases you need only specify -g for debugging, the target machine architecture, and the word-length. For example, to compile a single source file to execute under dbx on a Power Challenge XL, you could use the following commands:

f90 -g3 -O0 -o testcase testcase.f
dbx testcase

A program compiled in this way will take little advantage of the performance features of the machine. In particular, its speed when doing heavy floating-point calculations will be far slower than the machine is capable of. For simple programs, that is usually not relevant.

The options summarized in Table 1-1 tell the compiler how to treat the program source file.

---

Note: The Silicon Graphics Fortran 77 compiler supports a -dlines option that permits comment lines to begin with a “D” in column 1. This option is not supported by Fortran 90, and such comments will cause syntax errors.

---

The options summarized in Table 1-2 direct the operation of the cpp preprocessor.

The options summarized in Table 1-3 tell the compiler what input files to use.

---

Note: The -I option is used to specify search locations for three kinds of included files:

---

The options summarized in Table 1-4 tell the compiler what output files to generate.

The options summarized in Table 1-5 are used to specify the characteristics of the machine where the compiled program will be used. The TARG and TENV options are discussed in the MIPS Compiling and Performance Tuning Guide.

The options summarized in Table 1-6 tell the compiler how to allocate memory and how to align variables in it. These options can have a strong effect on both program size and program speed.

The options summarized in Table 1-7 direct the compiler to include more or less extra information in the object file for debugging or profiling.

For more information on debugging and profiling, see the MIPS Compiling and Performance Tuning Guide.

The MIPSpro Fortran 90 compiler contains three optimizer phases. One is part of the compiler “back end”; that is, it operates on the generated code, after all syntax analysis and source transformations are complete. The use of this standard optimizer, which is common to all MIPSpro compilers, is discussed in the MIPS Compiling and Performance Tuning Guide.

In addition, two phases of accelerators, one for scalar optimization and one for parallel array optimization, can be applied to the output of the front end. These optimizing phases are available only with the optional POWER Fortran 90 product. The options of the scalar optimizer are detailed in the fopt(1) reference page. The options of the parallel optimizer are detailed in the pfa(1) reference page.

The options summarized in Table 1-8 are used to communicate to the different optimization phases.

The GCM, OPT, and SWP options are discussed in detail in the MIPS Compiling and Performance Tuning Guide.

For the options that can follow -sopt, refer to the fopt(1) reference page. For the options that can follow -WK, refer to the pfa(1) reference page. For examples of -WK, see Table 1-9.

When you use -O to specify the optimization level, the compiler assumes default options for the accelerator phases. These defaults are listed in Table 1-9. Remember, to see all options that are passed to a compiler phase, use the -show option.

In addition to optimizing options, the compiler system provides other options that can improve the performance of your programs:

The options summarized in Table 1-10 control the execution of the compiler phases.

The -Yc and -Wc options take a single letter c to specify which compiler phase is meant. The letters are as follows:

For examples of using -W, see Table 1-9.

To execute a program, invoke it by name as a command. In the command environment where this happens, the run-time loader rld must be able to find all needed DSOs (see “Loading DSOs at Execution Time”).

A program can recover the command-line arguments using the getarg subroutine and iargc function (see the getarg(3f) reference page). The program in Example 1-4 lists its arguments using these functions.

external getarg, iargc
integer iargc
character(80) anarg
do j = 1, iargc()
   call getarg(j,anarg)
   write (6,"(i3,' = ',a)") j, anarg
end do
end ! program

In general, a program may use as much memory as necessary. There are some limits on individual allocations to 2 gigabytes (2,048 megabytes); and IRIX places global limits on run-time use of stack and allocated memory.

subroutine bloat(arg)
   integer arg
   integer, parameter :: ndim = 16380
   integer(8) xmat(ndim,ndim), ymat(ndim,ndim), & 
              zmat(ndim,ndim)
   xmat = arg
   return
end

function bigarg(rodan)
   integer rodan(8589934592_8)
   bigarg = rodan(4294967296_8)
end

Checking and Setting IRIX Limits

No user can have a stack larger than the current IRIX stack allocation limit nor can allocate total data memory greater than the IRIX data limit. Both these limits can be examined using the sh or csh command limit.

% limit stacksize stacksize 512000 kbytes % limit datasize datasize unlimited

---

Note: There is no warning or diagnostic message when a program exceeds the data or stack limit. The program ends with a segmentation fault.

---

You can use the limit command to set a smaller or larger limit, up to a system maximum. The system maximum (rlimit_data_max or rlimit_stack_max) is set using the systune command (refer to the systune(1) reference page).

This section covers the details of using files at runtime.

When the Fortran 90 run-time system detects an error that is not handled by the program, the following action takes place:

You can use dbx to locate the point of failure in the core file. To invoke dbx using the core file, enter this command:

% dbx executable-file

where executable-file is the name of the executable program. The dbx command where displays a stack trace showing the procedures that were active when the error took place.

---

Tip: When a program ends with a segmentation fault, a likely cause is that a memory size limit was exceeded. See “Program and Memory Size Limits”.

---

The library libfpe provides two methods for handling floating point exceptions.

---

Note: Owing to the different architecture of the MIPS R8000 and R10000 processors, library libfpe is not available with the current compiler. It will be provided in a future release. When porting Fortran 77 programs that depend on trapping exceptions using the facilities in libfpe, you will have to temporarily change the programs to do without it.

---

The library provides the subroutine handle_sigfpes and the environment variable TRAP_FPE. Both methods provide mechanisms for handling and classifying floating point exceptions, and for substituting new values. They also provide mechanisms to count, trace, exit, or abort on enabled exceptions. See the handle_sigfpes(3F) reference page for more information