Known Problems and Workarounds

When very large arrays are declared to be local to a subroutine, the arrays are privatized. This means that the arrays are allocated in stack space.Workaround: The default stack size for an OPENMP thread is 8 megabytes. This can be changed by setting the environment variable CPS_STACK_SIZE. For example, setenv CPS_STACK_SIZE 20000000 changes the stack size per thread from 8MB to 20MB.

HP Fortran only accepts the !$ALIAS directive, not $ALIAS.

A program compiled with “ +DA2.0W +check=all +fp_exception” results in a divide by zero trap during a subroutine call.

Compiling an array slice assignment at +O0 results in an internal compiler error.

Dummy arguments in multiple entry routines are not correctly handled by the WDB debugger.

Printing a dummy argument that is a CHARACTER in 64-bit wide mode (+DA2.0W) does not work in the WDB debugger.

When compiling, the +ppu switch is enabled by default. To access C routines, use the ALIAS directive to map the C routine name to itself. For example:

!$HP ALIAS getrusage=`getrusage’

If the ALIAS directive is not used, `getrusage’ is mapped to `getrusage_’ in the object file.

With +DD64, memory addresses are 64-bit values. This allows common blocks and dynamically allocated memory to exceed 32-bit address limits. This feature is restricted by the available virtual memory on the system where the application is run.

Common blocks greater than 2GBytes are automatically placed into a huge data segment and initialization is performed at program start-up.

Workaround: To force smaller common blocks into the huge data segment, use the +hugecommon and +hugesize compiler switches.

	NOTE: When using initialized huge common blocks, large repeat counts are represented compactly to help reduce object file size.

When creating 64-bit shared executables (such as when +DD64 is specified) the +Z option is on by default. The +Z option (equivalent to +pic=long) is the only PIC option supported for 64-bit executables. If the +z option (equivalent to +pic=short) is specified when creating 64-bit code, it instead maps to +Z.

Workaround: To not generate position independent code for 64-bit executables, specify the following option:

-Wl,-noshared

Mixing the standard Fortran  I/O operations with BUFFER IN and BUFFER OUT I/O on the same logical unit number can confuse the input stream (READ) or corrupt the data file (WRITE).

SoftBench support is not available.

Using the ON statement at optimization levels 2 and above is restricted. When compiling at optimization level 2 or above, the optimizer makes assumptions about the program that do not take into account the behavior of procedures called by the ON statement. Such procedures must therefore be “well-behaved”; they must meet the following criteria:

	NOTE: These restrictions do not apply if you compile at optimization levels +O0 and +O1.

The +DS compile-line options do not accept any PA-RISC architecture models as arguments because the HP Fortran compiler for Itanium®-based architectures does not support the PA-RISC architecture.

Pointer arithmetic on Cray-style pointers has different semantics on Hewlett-Packard machines than on some Cray machines. HP Fortran implements Cray pointers as BYTE pointers, while some Cray machines use word addressing.

Large source files occasionally cause internal errors in the HP Fortran compiler.

Workaround: If this occurs, split the file using fsplit and recompile.

The previous versions of Fortran occasionally contained a 'wrong answer' problem that is now caught by a compiler assert function at +O3 +Oparallel.

Workaround: To avoid this, use +O2 optimization instead of +O3.