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.

The wait system calls in the Fortran compilers generate different statuses when an unpreinstrumented Fortran application is run from CXperf. This is a compiler-specific issue, and not a problem with CXperf. If an application runs normally and returns status=child process terminated normally with a return code of zero, then a run from within CXperf will return *stat_loc or status=child process terminated with a SIG_TRAP. This is expected since the CXperf process interface uses a trapping mechanism to probe the application processes.

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 64-bit applications, 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 +DA2.0W, 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 +DA2.OW 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

Both the +pa and +pal options are ignored when the HP Fortran 90 compiler generates position-independent code (PIC). As a result, the following options cause +pa and +pal to be ignored: +pic=short, +pic=long, +z, and +Z.

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.

Program optimization using the +O4 option 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 +DA and +DS compile-line options do not accept 1.0 (or any PA-RISC 1.0 architecture models) as arguments because the HP Fortran compiler no longer supports the PA-RISC 1.0 architecture.

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

When +O3 +Oreport +pal is used, the Optimization Report contains extra loops with erroneous line numbers.

Workaround: To avoid this problem, use +Oinfo in place of +Oreport.

If you installed a patch that modified sched.models, you may have received the +DA1.1 code by default.

Workaround: If this is the case, you will need to specify the +DA2.0 option on each compile so that the compiler will generate code that will gain the benefits of the PA-RISC 2.0 architecture.

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.