Using porting options

Uninitialized variables

As noted in “Automatic and static variables”, the default behavior of HP Fortran 90 is to allocate storage for program variables from the stack. However, older implementations of Fortran often allocate static storage for variables. One of the differences between stack storage and static storage is that static variables are initialized to 0s by the compiler, whereas automatic variables (variables allocated from the stack) must be explicitly initialized by the programmer.

Programs written for implementations of Fortran that allocate static storage by default sometimes rely on the compiler to initialize variables. Compiling and executing such programs on implementations that allocate stack storage can have disastrous results. To make HP Fortran 90 compatible with implementations that allocate static storage, compile with the +save option. This option causes the compiler to act as though all local variables had the SAVE attribute.

As mentioned in “Automatic and static variables”, saving all variables in static storage can degrade performance. If performance is an issue, consider using the +Oinitcheck option. Unlike the +save option, +Oinitcheck does not "save" variables—it does not move variables into static storage. Instead, it causes the compiler to search for all local, nonarray, nonstatic variables that have not been defined before being used. Any that it finds are initialized to 0 on the stack each time the procedure in which they are declared is invoked.

For detailed information about the +save and +Oinitcheck options, see HP Fortran 90 Programmer's Reference.

Large word size

The word size of default integers, reals, and logicals in HP Fortran 90 is 4 bytes. However, some implementations of Fortran 90—notably, Cray—use an 8-byte word size. Programs written for these implementations may rely on the increased precision and range in their computations.

You can double the sizes of default integer, real, and logicals by compiling with the +autodbl option, making them compatible with implementations that use the larger word size. This option also doubles the sizes of items declared with the COMPLEX and DOUBLE PRECISION statements, but not the BYTE and DOUBLE COMPLEX) statements.

Increasing the size of double-precision items can degrade the performance of your program. If you do not need the extra precision for items declared with the DOUBLE PRECISION statement, use the +autodbl4 option, which increases single-precision items only. Compiling with this option results in items declared as default real and double precision real having the same precision—a violation of the Standard.

For usage information about the +autodbl and +autodbl4 options, see “Increasing default data sizes”). For detailed descriptions of these options, refer to the HP Fortran 90 Programmer's Reference.

One-trip DO loops

If a DO loop is coded so that its initial loop count is greater than its final loop count, standard Fortran 90 requires that the loop never execute. However, under some implementations of FORTRAN 66, if a DO loop is reached, it executes for at least one iteration, even if the DO variable is initialized to a value greater than the final value. This is called a one-trip DO loop.

To duplicate the behavior of a one-trip DO loop in an HP Fortran 90 program, compile with the +onetrip option. To see the effects of this option, consider the following program:

PROGRAM main
 
   DO 10 i = 2, 1
     PRINT *, "Should never happen in standard Fortran 90."
10 CONTINUE
END PROGRAM main

When compiled with the command line:

$ f90 test_loop.f90

the PRINT statement will never execute because the initial loop count is higher than the final loop count. To force the loop to execute at least once, compile it with the command line:

$ f90 +onetrip test_loop.f90

When you run the program now, it produces the output:

$ a.out
 Should never happen in standard Fortran 90.

Name conflicts

A common problem in porting Fortran programs is name conflicts: a user-written procedure may have the same name as an intrinsic procedure on the implementation to which you are porting, and the compiler selects the name of the intrinsic when you are expecting it to call the user-written procedure. For example, HP Fortran 90 provides the nonstandard intrinsic FLUSH. If your program contains an external procedure with the same name and the procedure is not declared with the EXTERNAL statement, the HP Fortran 90 compiler will assume that the reference is to the intrinsic.

One way to identify user routines that have the same names as HP-specific intrinsics is to compile the program with the +langlvl=90 option. This option causes the compiler to issue warnings for all HP extensions in the source code, including nonstandard intrinsics. You can then edit the source file to declare the procedure that the compiler assumes is an intrinsic with the EXTERNAL statement.

The following are programs that illustrate the preceding concepts.

Example 11-1 clash.f90

PROGRAM clash i = 4 j = int1(i) PRINT *, "j =", j END PROGRAM clash FUNCTION int1(i) int1 = i+1 END FUNCTION int1

If this is compiled as coded and without the +langlvl=90 option, the compiler will assume that the reference is to the HP intrinsic named INT1 and not to the external function. Executing the program will produce unexpected results, as appears in the following sample run:

$ f90 clash.f90
clash.f90
   program CLASH
   external function INT1
 
11 Lines Compiled
$ a.out
 j = 4

If the program is recompiled with the +langlvl=90 option, the compiler flags the name of what it assumes to be a nonstandard intrinsic as well as the nonstandard source format:

$ f90 +langlvl=90 clash.f90
   program CLASH
 
 i = 4
^
Warning 4 at (3:clash.f90) : Tab characters are an extension to
standard Fortran-90
 j = int1(i)
     ^
Warning 39 at (5:clash.f90) : This intrinsic function is an
extension to standard Fortran-90
   external function INT1
 
 int1 = i+1
^
Warning 4 at (10:clash.f90) : Tab characters are an extension to
standard Fortran-90
 
11 Lines Compiled

Once you have identified the names of your routines that clash with intrinsic names, you can edit the source code to declare each procedure with the EXTERNAL statement, as follows:

EXTERNAL int1

Now when you compile and execute, you will get the expected behavior:

$ f90 clash.f90
clash.f90
   program CLASH
   external function INT1
 
11 Lines Compiled
$ a.out
 j = 5

	NOTE: The name-conflict problem can occur in Fortran programs that call routines in the libU77.a library. Some implementations link libU77.a by default. HP Fortran 90 does not; to link in this library, you must compile your program with the +U77 option. If you do not compile with this option and your program references a libU77 routine with the same name as an HP Fortran 90 intrinsic, the compiler will wrongly (and sometimes disastrously) assume that the reference is to an intrinsic. If you are not sure if your program references libU77 routines, compile it with the +langlvl=90 option, which will cause the compiler to issue warnings for references to nonstandard routines. For problems that can occur when migrating HP FORTRAN 77 programs that reference libU77 routines, see “Intrinsic functions”.

Names with appended underscores

In some implementations of Fortran (but not HP Fortran 90), the compiler automatically appends underscores to external names. If you are porting a mixed-language program from such an implementation (for example, a program consisting of C and Fortran source files), the linker may not be able to find the names in the C code because the names in the Fortran code do not have the appended underscore. The reason is that the C code has explicitly added underscores to match the names of the Fortran procedures in the object code.

Using the +ppu option causes the HP Fortran 90 compiler to append an underscore to external names (including procedures and common blocks), making them consistent with the name as it appears in the non-Fortran source file. For example, if a Fortran source file contains the procedure proc_array, and a C source file reference this procedure as proc_array_, compiling the Fortran source file with the +ppu option causes the compiler to use proc_array_ as the name of the procedure in the Fortran object file.

For information about how to resolve other name conflicts in mixed-language programs, see “Case sensitivity”.

Source formats

Standard Fortran 90 permits source code in either fixed or free form, though not both in the same file. Furthermore, if the source is in fixed form, the Standard requires statements not to extend beyond column 72. Also, Standard Fortran 90 does not allow tab formatting.

HP Fortran 90's scheme for handling the different formatting possibilities is this:

See the HP Fortran 90 Programmer's Reference for detailed information about the different source and the +langlvl=90, +source, and +extend_source options.

Escape sequences

Some implementation of Fortran process certain characters preceded by the backslash (\) as a C-like escape sequence. For example, if a program containing the statement:

PRINT *, "a\nb\nc"

were compiled under an implementation that recognized escape sequences, the statement would output:

 a
b
c

When compiled in strict compliance with the Standard, the same statement would output:

 a\nb\nc

Although HP Fortran 90 does not recognize escape sequences by default, you can use the +escape option to make the compiler to recognize them. Refer to the HP Fortran 90 Programmer's Reference for more information about escape sequences.