What’s in This Version

For Itanium®-based systems only: Selects the +Ofast option at optimization level +O4. Equivalent to +Ofast +O3 -ipo.

For PA-RISC systems only: +Ofaster drops to +O3.

Enables interprocedural optimizations across files. Object files produced using this option contain intermediate code in IELF format. At linke time, ld automatically invokes the interprocedural optimizer u2comp if any of the input object files is an IELF file.

This option is ignored at optimization levels +O1 and +O2. It is enabled by default when +O4 or +Ofaster are used.

The behavior of this directive is similar to fsplit’ing a file and selectively choosing +Oopenmp or +Onoopenmp per each file.

In the absence of qualifiers, +Oprofile=collect is the same as +I. <qualifiers> are a comma-separated list of profile collection qualifiers. Supported profile collection qualifiers:

Interactions and dependencies are not changed with respect to +Oprofile=collect.

This option is now supported for the Itanium® processor family.

HP$OPTIMIZE, as listed below, is now supported for Fortran 90.

There are two types of allowable conversions:

When the CONVERT argument is specified to the OPEN statement, all I/O to that unit will undergo the specified conversions.

When the CONVERT argument is specified to the INQUIRE statement, a string is returned that describes the conversions being done at runtime for a given unit.

In addition to specifying the CONVERT parameter to the OPEN statement, there are two other methods for specifying the type of conversion to take place:

There are three ways to specify what file/unit should be converted, and which conversion to apply (in priority, with highest priority listed first):

Typically, code is written via the CONVERT=argument to OPEN and INQUIRE. Therefore, this option was given the higher priority status to allow overriding “normal” coding via the environment variable.

	NOTE: The CONVERT parameter to OPEN is only available via f90 version 2.7 or later, and is only accepted for UNFORMATTED files.

As a quick fix, add the following call to the main program:

call allow_unaligned_data_access( )

Then, link in an additional library that fixes these alignment issues at runtime:

-lunalign

Longer term, try compiling with the following flag:

+allow_unaligned

An example would be:

PROGRAM bs30
INTEGER*2 i2(10)
INTEGER*4 i4
EQUIVALENCE (i2(2), i4)
DATA I4 /z’FFFF0000’/
i4=12
    call allow_unaligned_data_access()
 
print *,i4
END

Then compile with:

/opt/fortran90/bin/f90 foo.f -lunalign +noppu

If you need to drop the +noppu, then add an alias directive as follows:

!$HP$ALIAS allow_unaligned_data_access=’allow_unaligned_data_access’

PROGRAM bs30
INTEGER*2 i2(10)
INTEGER*4 i4
EQUIVALENCE (i2(2), i4)
DATA I4 /z’FFFF0000’/
i4=12
    call allow_unaligned_data_access()
 
print *,i4
END

Then compile with:

/opt/fortran90/bin/f90 foo.f -lunalign

	NOTE: Nothing new is required to use the aforementioned -lunalign runtime fix approach; however, you do need the latest patch for the +allow_unaligned compile flag.

If the misaligned data might be passed to routines which are not compiled with +allow_unaligned (for example, Fortran runtime IO and F90 libraries), then having the call will allow the runtime fixes to happen which will prevent bus errors in your application.

To realize optimum performance, try and measure the following two options:

Option #1 may perform faster with very few references to misaligned data and a handler is invoked for these misaligned references. #2 may perform faster with many references.

Complete information about this feature is available in the Parallel Programming Guide for HP-UX Systems.

-L/opt/fortran90/lib/ -lF90 -lisamstub

-L/opt/fortran90/lib/pa2.0/ -lF90 -lisamstub

-L/opt/fortran90/lib/pa20_64/ -lF90 -lisamstub

HP Caliper 3.0 includes the following documentation: