3.4 Options Reference

This section describes all of the f95compiler command–line option flags, including various risks,
restrictions, caveats, interactions, examples, and other details.

Unless indicated otherwise, each option is valid on both SPARC and x64/x86
platforms. Option flags valid only on SPARC platforms are marked (SPARC). Option flags valid only on x64/x86 platforms
are marked (x86).

Option flags marked (Obsolete) are obsolete and should not be used. In many cases
they have been superceded by other options or flags that should be used instead.

3.4.1 –a

(Obsolete) Profile by basic block using tcov,
old style.

This is the old style of basic block profiling for tcov.
See -xprofile=tcov for information on the new style
of profiling and the tcov(1) man page for more details.

3.4.2 –aligncommon[={1|2|4|8|16}]

Specify the alignment of data in common blocks and standard numeric
sequence types.

The value indicates the maximum alignment (in bytes) for data elements
within common blocks and standard numeric sequence types.

Note –

A standard numeric sequence type is a derived type containing
a SEQUENCE statement and only default component data
types ( INTEGER,REAL,DOUBLEPRECISION,COMPLEX without KIND= or *size) . Any other type, such as REAL*8, will
make the type non-standard.

For example, -aligncommon=4 would align data
elements with natural alignments of 4 bytes or more on 4-byte boundaries.

This option does not affect data with natural alignment smaller than
the specified size.

Without -aligncommon, the compiler aligns elements
in common blocks and numeric sequence types on (at most) 4-byte boundaries.

Specifying -aligncommon without a value defaults
to 1 - all common block and numeric sequence type elements align on byte boundaries
(no padding between elements).

-aligncommon=16 reverts to -aligncommon=8 on platforms that are not 64-bit enabled.

3.4.3 –ansi

Identify many nonstandard extensions.

Warning messages are issued for any uses
of non–standard Fortran 95 extensions in the source code.

3.4.4 –arg=local

Preserve actual arguments over ENTRY statements.

When you compile a subprogram with alternate entry points with this
option, f95 uses copy/restore to preserve the association
of dummy and actual arguments.

This option is provided for compatibility with legacy Fortran 77 programs.
Code that relies on this option is non-standard.

3.4.5 –autopar

Enable automatic loop parallelization.

Finds and parallelizes appropriate loops for running
in parallel on multiple processors. Analyzes loops for inter–iteration
data dependencies and loop restructuring. If the optimization level is not
specified -O3 or higher, it will automatically be raised
to -O3.

Also specify the -stackvar option when using
any of the parallelization options, including -autopar.
The -stackvar option may provide better performance
when using -autopar because it may allow the optimizer
to detect additional opportunities for parallelization. See the
description of the -stackvar option for information
on how to set the sizes for the main thread stack and for the slave thread
stacks.

Avoid -autopar if the program already contains
explicit calls to the libthread threads library. See
note in 3.4.60 –mt.

The -autopar option is not appropriate on a single–processor
system, and the compiled code will generally run slower.

To run a parallelized program in a multithreaded environment, you must
set the PARALLEL (or OMP_NUM_THREADS)
environment variable prior to execution. This tells the runtime system the
maximum number of threads the program can create. The default is 1. In general,
set the PARALLEL or OMP_NUM_THREADS variable
to the number of available virtual processors on the target platform, which
can be determined by using the Solaris psrinfo(1) command.

If you use -autopar and
compile and link in one step, the multithreading library
and the thread–safe Fortran runtime library will automatically be linked.
If you use -autopar and compile and link in separate steps, then you must also link with -autopar to
insure linking the appropriate libraries.

The—reduction option may also be useful
with —autopar.

Refer to the Fortran Programming Guide for more
information on parallelization. For explicit, user-controlled parallelization,
use OpenMP directives and the —xopenmp option.

3.4.6 –B{static|dynamic}

Prefer dynamic or require static library linking.

No space is allowed between -B and dynamic or static. The default, without -B specified, is -Bdynamic.

–Bdynamic:
Prefer dynamic linking (try for shared libraries).

–Bstatic:
Require static linking (no shared libraries).

Also note:

If you specify static, but the linker
finds only a dynamic library, then the library is not linked with a warning
that the “library was not found.”

If you specify dynamic, but the linker
finds only a static version, then that library is linked, with no warning.

You can toggle -Bstatic and -Bdynamic on
the command line. That is, you can link some libraries statically and some
dynamically by specifying -Bstatic and -Bdynamic any number of times on the command line, as follows:

f95 prog.f -Bdynamic -lwells -Bstatic -lsurface

These are loader and linker options. Compiling
and linking in separate steps with -Bx on
the compile command will require it in the link step as well.

You cannot specify both -Bdynamic and -dn on the command line because -dn disables
linking of dynamic libraries.

In a 64-bit Solaris environment, many system libraries are available
only as shared dynamic libraries. These include libm.so and libc.so (libm.a and libc.a are
not provided). This means that -Bstatic and -dn may cause linking errors in 64-bit Solaris environments. Applications
must link with the dynamic libraries in these cases.

Mixing static Fortran runtime system libraries with dynamic Fortran
runtime system libraries is not recommended and can result in linker
errors or silent data corruption. Always link with the latest shared dynamic
Fortran runtime system libraries.

See the Fortran Programming Guide for more information
on static and dynamic libraries.

3.4.7 –C

Check array
references for out of range subscripts and conformance at runtime.

Subscripting arrays beyond their declared sizes may result in unexpected
results, including segmentation faults. The -C option
checks for possible array subscript violations in the source code and during
execution. -C also adds runtime checks for array conformance
in array syntax expressions

Specifying -C may make the executable file larger.

If the -C option is used, array subscript violations
are treated as an error. If an array subscript range violation is detected
in the source code during compilation, it is treated as a compilation error.

If an array subscript
violation can only be determined at runtime, the compiler generates range–checking
code into the executable program. This may cause an increase in execution
time. As a result, it is appropriate to enable full array subscript checking
while developing and debugging a program, then recompiling the final production
executable without subscript checking.

3.4.8 –c

Compile only; produce object .o files, but suppress
linking.

Compile a .o file
for each source file. If only a single source file is being compiled, the -o option can be used to specify the name of the .o file
written.

3.4.9 –cg89

(Obsolete, SPARC) Compile for generic SPARC architecture.

This option is a macro for: -xarch=v7 -xchip=old -xcache=64/32/1 which is equivalent to -xtarget=ss2.

3.4.10 –cg92

(Obsolete, SPARC) Compile for SPARC V8 architecture.

This option is a macro for:–xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1 which
is equivalent to -xtarget=ss1000.

3.4.11 –copyargs

Allow assignment to constant arguments.

Allow a subprogram to change a dummy argument that is a constant.
This option is provided only to allow legacy code to compile and execute without
a runtime error.

Without -copyargs, if you pass a constant
argument to a subroutine, and then within the subroutine try to change that
constant, the run aborts.

With -copyargs, if you pass a constant
argument to a subroutine, and then within the subroutine change that constant,
the run does not necessarily abort.

Code that aborts unless compiled with -copyargs is,
of course, not Fortran standard compliant. Also, such code is often unpredictable.

3.4.12 –Dname[=def]

Define symbol name for
the preprocessor.

This option only
applies to .F, .F90, .F95, and .F03 source files.

–Dname=def
Define name to have value def

–Dname
Define name to be 1

On the command line, this option will define name as
if:

#definename[=def]

had appears in the source file. If no =def specified, the name name is defined
as the value 1. The macro symbol name is passed
on to the preprocessor fpp (or cpp—
see the -xpp option) for expansion.

The predefined macro symbols have two leading underscores. The Fortran
syntax may not support the actual values of these macros—they should
appear only in fpp or cpp preprocessor
directives. (Note the two leading underscores.)

The product version is predefined (in hex) in _
_SUNPRO_F90, and _ _SUNPRO_F95. For example _ _SUNPRO_F95 is 0x830 for the Sun Studio
12 release.

The following are predefined with no underscores, but they
might be deleted in a future release: sparc, unix, sun

On SPARC V9 systems, the _ _sparcv9 macro
is also defined.

On 64-bit x86 systems, the macros __amd64 and __x86_64 are defined.

Compile with the verbose option (-v) to see the
definitions created by the compiler.

You can use these values in such preprocessor conditionals as the following:

#ifdef _ _sparc

f95 uses the fpp(1)
preprocessor by default. Like the C preprocessor cpp(1), fpp expands source code macros and
enables conditional compilation of code. Unlike cpp, fpp understands Fortran syntax, and is preferred as a Fortran
preprocessor. Use the -xpp=cpp flag to force the compiler
to specifically use cpp rather than fpp.

3.4.13 –dalign

This flag changes the data layout in COMMON blocks, numeric sequence
types, and EQUIVALENCE classes, and enables the compiler to generate faster
multi-word load/stores for that data.

The data layout effect is that of the -f flag:
double- and quad-precision data in COMMON blocks and EQUIVALENCE classes are
laid out in memory along their “natural” alignment, which is on
8-byte boundaries (or on 16-byte boundaries for quad-precision when compiling
for 64-bit environments with -m64). The default alignment
of data in COMMON blocks is on 4-byte boundaries. The compiler is also allowed
to assume natural alignment and generate faster multi-word load/stores to
reference the data.

Using -dalign along with -xtypemap=real:64,double:64,integer:64 also causes 64-bit integer variables to be double-word aligned
on SPARC processors.

Note –

-dalign may result in nonstandard alignment
of data, which could cause problems with variables in EQUIVALENCE or COMMON and
may render the program non-portable if -dalign is
required.

-dalign is a macro equivalent to:

-xmemalign=8s-aligncommon=16on SPARC platforms

-aligncommon=8on 32-bit x86 platforms

-aligncommon=16on 64-bit x86 platforms.

If you compile one subprogram with -dalign, compile
all subprograms of the program with -dalign. This option
is included in the -fast option.

3.4.14 –dbl_align_all[={yes|no}]

The value is either yes or no.
If yes, all variables will be aligned on 8–byte
boundaries. Default is -dbl_align_all=no.

When compiling for 64-bit environments with -m64,
this flag will align quad-precision data on 16-byte boundaries.

This flag does not alter the layout of data in COMMON blocks or user-defined
structures.

Use with -dalign to enable added efficiency with
multi-word load/stores.

If used, all routines must be compiled with this flag.

3.4.15 –depend[={yes|no}]

Analyze loops for
data dependencies and do loop restructuring.

Dependence analysis is enabled with -depend or -depend=yes. The analysis is disabled with -depend=no,
which is the compiler default.

This option will raise the optimization level to O3 if
no optimization level is specified, or if it is specified less than O3. -depend is also included with -fast, -autopar and -parallel.
Note also that specifying an optimization level -O3 or
higher automatically adds -depend. (See the Fortran
Programming Guide.)

3.4.16 –dn

3.4.17 –dryrun

Show commands built by the f95 command-line driver,
but do not compile.

Useful when debugging, this option displays the commands and suboptions
the compiler will invoke to perform the compilation.

3.4.18 –d{y|n}

Allow or disallow dynamic libraries for the entire executable.

–dy: Yes, allow dynamic/shared libraries.

–dn: No, do not allow dynamic/shared
libraries.

The default, if not specified, is -dy.

Unlike -Bx, this option
applies to the whole executable and need appear only
once on the command line.

–dy|–dn are loader and linker options. If you compile and link in separate steps
with these options, then you need the same option in the link step.

In a 64-bit Solaris environment, many system libraries are not available
only as shared dynamic libraries. These include libm.so and libc.so (libm.a and libc.a are
not provided). This means that -dn and -Bstatic may cause linking errors in 64-bit Solaris environments and 32-bit
x86 Solaris platforms, and all 32-bit Solaris platforms starting with the
Solaris 10 release. Applications must link with the dynamic libraries in these
cases.

3.4.19 –e

Accept extended length input source line.

Extended source lines can be up to 132 characters long. The compiler
pads on the right with trailing blanks to column 132. If you use continuation
lines while compiling with -e, then do not split character
constants across lines, otherwise, unnecessary blanks may be inserted in the
constants.

3.4.20 –erroff[={%all|%none|taglist}]

Suppress warning messages listed by tag name.

Suppress the display of warning messages specified in the comma–separated
list of tag names taglist. If %all,
suppress all warnings, which is equivalent to the -w option. If %none, no warnings are suppressed. —erroff without an argument is equivalent to —erroff=%all.

Example:

f95 -erroff=WDECL_LOCAL_NOTUSED ink.f

Use the -errtags option to see the tag names
associated with warning messages.

3.4.21 –errtags[={yes|no}]

Display the message tag with each warning message.

With-errtags=yes, the compiler’s internal error tag name will appear along
with warning messages. -errtags alone is equivalent
to -errtags=yes.

3.4.23 –explicitpar

This option enables legacy Sun or Cray parallelization directives.
These directives and parallelization model are deprecated and no longer supported.
The OpenMP API is the preferred and supported parallelization model. See the
-xopenmp option and the OpenMP API User’s
Guide for details on converting Sun/Cray directives to OpenMP.

The compiler will
generate parallel code even if there are data dependencies in the DO loop
that would cause the loop to generate incorrect results when run in parallel.
With explicit parallelization, it is the user’s responsibility to correctly
analyze loops for data dependency problems before marking them with parallelization
directives.

-explicitpar should not be used to compile programs
that already do their own multithreading with calls to the libthread library.

To run a parallelized program in a multithreaded environment, you must
set the PARALLEL (or OMP_NUM_THREADS)
environment variable prior to execution. This tells the runtime system the
maximum number of threads the program can create. The default is 1. In general,
set the PARALLEL or OMP_NUM_THREADS variable
to the number of available virtual processors on the target platform. (See psrinfo(1)).

If you use -explicitpar and compile and link in one step,
then linking automatically includes the multithreading library and the thread–safe
Fortran runtime library. If you use -explicitpar and
compile and link in separate steps, then you must also link with -explicitpar.

To improve performance, also specify the -stackvar option
when using any of the parallelization options, including -explicitpar.

Use the -mp option (3.4.59 –mp={%none|sun|cray}) to select the style of parallelization directives enabled. The default
with -explicitpar is Sun directives. Use -explicitpar-mp=cray to enable Cray directives.

If the optimization level is not -O3 or higher,
it is raised to -O3 automatically.

For details, see the “Parallelization” chapter in the Fortran Programming Guide.

3.4.24 –ext_names=e

Create external names with or without trailing underscores.

e must be either plain or underscores. The default is underscores.

–ext_names=plain: Do not add trailing underscore.

–ext_names=underscores: Add trailing underscore.

An external name is a name of a subroutine, function, block data subprogram,
or labeled common. This option affects both the name of the routine’s
entry point and the name used in calls to it. Use this flag to allow Fortran
95 routines to call (and be called by) other programming language routines.

3.4.25 –F

Invoke the source file preprocessor, but do not compile.

Apply the fpp preprocessor to .F, .F90, .F95, and .F03 source
files listed on the command line, and write the processed result on a file
with the same name but with filename extension changed to .f (or .f95 or .f03), but do not compile.

Example:

f95 -F source.F

writes the processed source file to source.f

fpp is the default preprocessor for Fortran.
The C preprocessor, cpp, can be selected instead
by specifying -xpp=cpp.

3.4.26 –f

Align double- and quad-precision data in COMMON blocks.

-f is a legacy option flag equivalent to -aligncommon=16. Use of -aligncommon is
preferred.

The default alignment of data in COMMON blocks is on 4-byte boundaries.
-f changes the data layout of double- and quad-precision
data in COMMON blocks and EQUIVALENCE classes to be placed in memory along
their “natural” alignment, which is on 8-byte boundaries (or on
16-byte boundaries for quad-precision when compiling for 64-bit SPARC environments
with -m64).

Note –

-f may result in nonstandard alignment
of data, which could cause problems with variables in EQUIVALENCE or COMMON and
may render the program non-portable if -f is
required.

Compiling any part of a program with -f requires
compiling all subprograms of that program with -f.

By itself, this option does not enable the compiler to generate faster
multi-word fetch/store instructions on double and quad precision data. The -dalign option does this and invokes -f as
well. Use of -dalign is preferred over the older -f. See 3.4.13 –dalign. Because -dalign is part of the -fast option, so
is -f.

3.4.27 –f77[=list]

Select Fortran 77 compatibility mode.

This option flag enables porting legacy Fortran 77 source programs,
including those with language extensions accepted by the f77 compiler,
to the f95 Fortran 95 compiler.

list is a comma-separated list selected from
the following possible keywords:

Enable f77-style TAB-formatting, including unlimited
source line length. No blank padding will be added to source lines shorter
than 72 characters.

All keywords can be prefixed by no% to disable
the feature, as in:

-f77=%all,no%backslash

The default, when -f77 is not specified, is -f77=%none. Using -f77 without a list is
equivalent to specifying -f77=%all.

Exceptions Trapping and-f77:

Specifying -f77 does not change the Fortran 95
trapping mode, which is -ftrap=common. Fortran 95 differs
from the Fortran 77 compiler’s behavior regarding arithmetic exception
trapping. The Fortran 77 compiler allowed execution to continue after an arithmetic
exception occurred. Compiling with -f77 also causes
the program to call ieee_retrospective on program exit
to report on any arithmetic exceptions that might have occurred. Specify -ftrap=%none following the -f77 option
flag on the command line to mimic the original Fortran 77 behavior.

See also the -xalias flag for handling non-standard
programming syndromes that may cause incorrect results.

3.4.28 –fast

Select options that optimize execution performance.

Note –

This option is defined as a particular selection of other options
that is subject to change from one release to another, and between compilers.
Also, some of the options selected by -fast might
not be available on all platforms. Compile with the -dryrun flag
to see the expansion of -fast.

-fast provides high performance
for certain benchmark applications. However, the particular choice of options
may or may not be appropriate for your application. Use -fast as
a good starting point for compiling your application for best performance.
But additional tuning may still be required. If your program behaves improperly
when compiled with -fast, look closely at the individual
options that make up -fast and invoke only those appropriate
to your program that preserve correct behavior.

Note also that a program compiled with -fast may
show good performance and accurate results with some data sets, but not with
others. Avoid compiling with -fast those programs that
depend on particular properties of floating-point arithmetic.

Because some of the options selected by -fast have
linking implications, if you compile and link in separate steps be sure to
link with -fast also.

–fast selects the following options:

The -xtarget=native hardware target. If
the program is intended to run on a different target than the compilation
machine, follow the -fast with a code–generator
option. For example: f95 -fast -xtarget=ultraT2 ...

The -O5optimization level option.

The -dependoption analyzes
loops for data dependencies and possible restructuring.

The -libmiloption for
system–supplied inline expansion templates. For
C functions that depend on exception handling, follow -fast by -nolibmil (as in -fast -nolibmil).
With -libmil, exceptions cannot be detected with errno or matherr(3m).

The -fsimple=2option
for aggressive floating–point optimizations.–fsimple=2 is unsuitable if strict IEEE 754 standards compliance
is required. See 3.4.39 –fsimple[={1|2|0}].

The -dalignoption to
generate double loads and stores for double and quad data in common blocks.
Using this option can generate nonstandard Fortran data alignment in common
blocks.

The -xlibmopt option selects
optimized math library routines.

-pad=localinserts padding between local variables, where appropriate, to
improve cache usage. (SPARC)

-xvector=libtransforms
certain math library calls within DO loops to single calls to a vectorized
library equivalent routine with vector arguments. (SPARC)

-fround=nearest is selected because —xvector and —xlibmopt require
it. (Solaris)

Trapping on common floating-point exceptions, -ftrap=common, is the enabled with Fortran 95.

-nofstore cancels forcing expressions
to have the precision of the result. (x86)

-xregs=frameptr allows the compiler
to use the frame-pointer register as an unallocated callee-saves register.
Specify -xregs=no%frameptr after -fast and
the frame pointer register will not be used as a general purpose register.
(x86)

It is possible to add or subtract from this list by following the -fast option with other options, as in:

f95 -fast -fsimple=1 -xnolibmopt ...

which overrides the -fsimple=2 option and disables
the -xlibmopt selected by -fast.

Because -fast invokes -dalign, -fns, -fsimple=2, programs compiled with -fast can result in nonstandard floating-point arithmetic, nonstandard
alignment of data, and nonstandard ordering of expression evaluation. These
selections might not be appropriate for most programs.

Note that the set of options selected by the -fast flag
can change with each compiler release. Invoking the compiler with -dryrun displays the -fast exapansion:

3.4.29 –fixed

All
source files on the command–line will be interpreted as fixed format
regardless of filename extension. Normally, f95 interprets
only .f files as fixed format, .f95 as
free format.

3.4.30 –flags

Synonym for -help.

3.4.31 -fma={none|fused}

(SPARC) Enable automatic generation
of floating-point, fused, multiply-add instructions. -fma=none disables
generation of these instructions. -fma=fused allows
the compiler to attempt to find opportunities to improve the performance
of the code by using floating-point, fused, multiply-add instructions. The
default is -fma=none.

Minimum requirements are -xarch=sparcfmaf and
an optimization level of at least -xO2 for the compiler
to generate fused multiply-add instructions. The compiler will mark the binary
program if fused multiply-add instructions have been generated to prevent
execution of the program on platforms that do not support them.

3.4.32 –fnonstd

Initialize floating–point hardware to non–standard preferences.

This option is a macro for the combination of the following option flags:

–fns -ftrap=common

Specifying -fnonstd is approximately equivalent
to the following two calls at the beginning of a Fortran main program.

Flush underflow results to zero if it will improve speed,
rather than produce a subnormal number as the IEEE standard requires.

See -fns for more information about gradual underflow
and subnormal numbers.

The -fnonstd option allows hardware traps
to be enabled for floating–point overflow, division by zero, and invalid
operation exceptions. These are converted into SIGFPE signals, and if the
program has no SIGFPE handler, it terminates with a dump of
memory.

For more information, see the ieee_handler(3m)
and ieee_functions(3m) man pages, the Numerical
Computation Guide, and the Fortran Programming Guide.

3.4.33 –fns[={yes|no}]

Select nonstandard floating–point mode.

The default is the standard floating–point mode (–fns=no). (See the “Floating–Point Arithmetic” chapter
of the Fortran Programming Guide.)

Optional use of =yes or =no provides
a way of toggling the -fns flag following some other
macro flag that includes it, such as -fast. -fns without a value is the same as -fns=yes.

This option flag enables nonstandard floating-point mode when the program
begins execution. On SPARC platforms, specifying nonstandard floating-point
mode disables “gradual underflow”, causing tiny results to be
flushed to zero rather than producing subnormal numbers. It also causes subnormal
operands to be silently replaced by zero. On those SPARC systems that do not
support gradual underflow and subnormal numbers in hardware, use of this option
can significantly improve the performance of some programs.

Where x does not cause total underflow, x is a subnormal number if and only if |x|
is in one of the ranges indicated:

Table 3–8 Subnormal REAL and DOUBLE

Data Type

Range

REAL

0.0 < |x| < 1.17549435e–38

DOUBLE PRECISION

0.0 < |x| < 2.22507385072014e–308

See the Numerical Computation Guide for details
on subnormal numbers, and the Fortran Programming Guide chapter “Floating–Point
Arithmetic” for more information about this and similar options. (Some
arithmeticians use the term denormalizednumber for subnormal number.)

The standard initialization of floating–point preferences is the
default:

On x86 platforms, this option is enabled only for Pentium III and Pentium
4 processors (sse or sse2 instruction sets).

On x86, -fns selects SSE flush-to-zero mode and
where available, denormals-are-zero mode. This flag causes subnormal results
to be flushed to zero. Where available, this flag also causes subnormal operands
to be treated as zero. This flag has no effect on traditional x87 floating-point
operations not utilizing the SSE or SSE2 instruction set.

To be effective, the main program must be compiled with this option.

3.4.34 –fpover[={yes|no}]

Detect floating-point overflow in formatted input.

With -fpover=yes specified, the I/O library will
detect runtime floating-point overflows in formatted input and return an error
condition (1031). The default is no such overflow detection (–fpover=no). -fpover without a value is equivalent
to -fpover=yes. Combine with —ftrap to
get full diagnostic information.

3.4.35 –fpp

Force preprocessing of input with fpp.

Pass all the input source files listed on the f95 command
line through the fpp preprocessor, regardless of file
extension. (Normally, only files with .F, .F90,
or .F95 extension are automatically preprocessed by fpp.) See also 3.4.162 –xpp={fpp|cpp}.

3.4.36 –fprecision={single|double|extended}

(x86)
Initialize non-default floating-point rounding precision mode.

On x86, sets the floating-point precision
mode to either single, double,
or extended.

With a value of single or double,
this flag causes the rounding precision mode to be set to single or double
precision respectively at program initiation. With extended,
or by default when the -fprecision flag is not specified,
the rounding precision mode is initialized to extended precision.

This option is effective only on x86 systems and only if used when compiling
the main program.

3.4.37 –free

Specify free–format source input files.

All source files on the command–line will be interpreted
as f95 free format regardless of filename extension.
Normally, f95 interprets .f files
as fixed format, .f95 as free format.

3.4.38 –fround={nearest|tozero|negative|positive}

Set the IEEE rounding mode in effect at startup.

The default
is -fround=nearest.

To be effective, compile the main program with this option.

This option sets the IEEE 754 rounding mode that:

Can be used by the compiler in evaluating constant expressions.

Is established at runtime during the program initialization.

When the value is tozero, negative,
or positive, the option sets the rounding direction
to round-to-zero, round-to-negative-infinity,
or round-to-positive-infinity, respectively, when the
program begins execution. When -fround is not specified, -fround=nearest is used as the default and the rounding direction
is round-to-nearest. The meanings are the same as those
for the ieee_flags function. (See the “Floating–Point
Arithmetic” chapter of the Fortran Programming Guide.)

3.4.39 –fsimple[={1|2|0}]

Select floating–point optimization preferences.

Allow the optimizer to make
simplifying assumptions concerning floating–point arithmetic. (See the “Floating–Point
Arithmetic” chapter of the Fortran Programming Guide.)

For consistent results, compile all units of a program with the same -fsimple option.

Computations producing no visible result other than potential
floating point exceptions may be deleted.

Computations with Infinity or NaNs (“Not a Number”)
as operands need not propagate NaNs to their results; for example, x*0 may be replaced by 0.

Computations do not depend on sign of zero.

With -fsimple=1, the optimizer is not allowed
to optimize completely without regard to roundoff or exceptions. In particular,
a floating–point computation cannot be replaced by one that produces
different results with rounding modes held constant at run time.

–fsimple=2

In addition to —fsimple=1, permit
aggressive floating point optimizations. This can cause some programs to produce
different numeric results due to changes in the way expressions are evaluated.
In particular, the Fortran standard rule requiring compilers to honor explicit
parentheses around subexpressions to control expression evaluation order may
be broken with -fsimple=2. This could result in numerical
rounding differences with programs that depend on this rule.

For example, with -fsimple=2, the compiler may
evaluate C-(A-B) as (C-A)+B,
breaking the standard’s rule about explicit parentheses, if the resulting
code is better optimized. The compiler might also replace repeated computations
of x/y with x*z, where z=1/y is computed once
and saved in a temporary, to eliminate the costly divide operations.

Programs that depend on particular properties of floating-point arithmetic
should not be compiled with -fsimple=2.

Even with -fsimple=2, the optimizer still is
not permitted to introduce a floating point exception in a program that otherwise
produces none.

–fast selects -fsimple=2.

3.4.40 –fstore

(x86) Force precision of floating-point
expressions.

For assignment statements, this option
forces all floating-point expressions to the precision of the destination
variable. This is the default. However, the -fast option
includes -nofstore to disable this option. Follow -fast with -fstore to turn this option
back on.

3.4.41 –ftrap=t

Set floating–point trapping mode in effect at startup.

t is a comma–separated list that consists
of one or more of the following:

The f95 default is -ftrap=common.
This differs from the C and C++ compiler defaults, which is -ftrap=none.

Sets the IEEE 745 trapping mode in effect at startup but does not install
a SIGFPE handler. You can use ieee_handler(3M) or fex_set_handling(3M) to simultaneously enable traps and install
a SIGFPE handler. If you specify more than one value, the list is processed
sequentially from left to right. The common exceptions, by definition, are
invalid, division by zero, and overflow.

Example: -ftrap=%all,no%inexact means set all
traps, except inexact.

The meanings for -ftrap=t are
the same as for ieee_flags(), except that:

%all turns on all the trapping modes,
and will cause trapping of spurious and expected exceptions. Use common instead.

%none turns off all trapping modes.

A no% prefix turns off that specific
trapping mode.

To be effective, compile the main program with this option.

For further information, see the “Floating–Point Arithmetic”
chapter in the Fortran Programming Guide.

3.4.42 –G

Build a dynamic shared library
instead of an executable file.

Direct the linker to build a shareddynamic library.
Without -G, the linker builds an executable file. With -G, it builds a dynamic library. Use -o with -G to specify the name of the file to be written. See the Fortran Programming Guide chapter “Libraries” for
details.

3.4.43 –g

Compile for debugging and performance analysis.

Produce additional symbol table information for debugging with dbx(1) debugging utility and for performance analysis with the Performance
Analyzer.

Although some debugging is possible without specifying -g,
the full capabilities of dbx and debugger are
only available to those compilation units compiled with -g.

Some capabilities of other options specified along with -g may be limited. See the dbx documentation
for details.

To use the full capabilities of the Performance Analyzer, compile with -g. While some performance analysis features do not require -g, you must compile with -g to view annotated
source, some function level information, and compiler commentary messages.
(See the analyzer(1) man page and the manual Sun
Studio Performance Analyzer.)

The commentary messages generated with -g describe
the optimizations and transformations the compiler made while compiling your
program. The messages, interleaved with the source code, can be displayed
by the er_src(1) command.

Note that commentary messages only appear if the compiler actually performed
any optimizations. You are more likely to see commentary messages when you
request high optimization levels, such as with -xO4,
or -fast.

3.4.44 –hname

Specify the name of the generated dynamic shared library.

This option is passed on to the linker. For details, see the Solaris Linker and Libraries Guide, and the Fortran Programming
Guide chapter “Libraries.”

The -hname option
records the name name to the shared dynamic library
being created as the internal name of the library. A space between -h and name is optional (except if the library name is elp,
for which the space will be needed). In general, name must
be the same as what follows the -o. Use of this option
is meaningless without also specifying -G.

Without the -hname option,
no internal name is recorded in the library file.

If the library has an internal name, whenever an executable program
referencing the library is run the runtime linker will search for a library
with the same internal name in any path the linker is searching. With an internal
name specified, searching for the library at runtime linking is more flexible.
This option can also be used to specify versions of shared
libraries.

If there is no internal name of a shared library, then the linker uses
a specific path for the shared library file instead.

3.4.45 –help

3.4.46 –Ipath

Insert the directory path path at the
start of the INCLUDE file search path. No space is
allowed between -I and path.
Invalid directories are ignored with no warning message.

The include file search path is the list of directories
searched for INCLUDE files—file names appearing
on preprocessor #include directives, or Fortran INCLUDE statements.

Example: Search for INCLUDE files in /usr/app/include:

demo% f95 -I/usr/app/include growth.F

Multiple -Ipath options
may appear on the command line. Each adds to the top of the search path list
(first path searched).

The search order for relative paths on INCLUDE or #include is:

The directory that contains the source file

The directories that are named in the -I options

The directories in the compiler’s internal default list

/usr/include/

To invoke the preprocessor, you must be compiling source files with
a .F, .F90, .F95,
or .F03 suffix.

3.4.47 -i8

(There is noi8option.)

Use —xtypemap=integer:64 to specify 8–byte INTEGER with this compiler.

3.4.48 –inline=[%auto][[,][no%]f1,…[no%]fn]

Enable or disable inlining of specified routines.

Request the optimizer to inline the user–written
routines appearing in a comma-separated list of function and subroutine names.
Prefixing a routine name with no% disables inlining
of that routine.

Inlining is an optimization technique whereby the compiler effectively
replaces a subprogram reference such as a CALL or function
call with the actual subprogram code itself. Inlining often provides the optimizer
more opportunities to produce efficient code.

Specify %auto to enable automatic inlining at
optimization levels -O4 or -O5.
Automatic inlining at these optimization levels is normally turned off when
explicit inlining is specified with -inline.

Example: Inline the routines xbar,zbar,vpoint:

demo% f95 -O3 -inline=xbar,zbar,vpoint *.f

Following are the restrictions; no warnings are issued:

Optimization must be -O3 or greater.

The source for the routine must be in the file being compiled,
unless -xipo or–xcrossfile are
also specified.

The compiler determines if actual inlining is profitable and
safe.

The appearance of -inline with -O4 disables
the automatic inlining that the compiler would normally perform, unless %auto is also specified. With -O4, the
compilers normally try to inline all appropriate user–written subroutines
and functions. Adding -inline with -O4 may
degrade performance by restricting the optimizer’s inlining to only
those routines in the list. In this case, use the %auto suboption
to enable automatic inlining at -O4 and -O5.

demo% f95 -O4 -inline=%auto,no%zpoint *.f

In the example above, the user has enabled -O4’s
automatic inlining while disabling any possible inlining of the routine zpoint() that the compiler might attempt.

3.4.49 –iorounding[={compatible|processor-defined}]

Set floating-point rounding mode for formatted input/output.

Sets the ROUND= specifier globally for all formatted
input/output operations.

With -iorounding=compatible, the value resulting
from data conversion is the one closer to the two nearest representations,
or the value away from zero if the value is halfway between them.

With -iorounding=processor-defined, the rounding
mode is the processor’s default mode. This is the default when -iorounding is not specified.

3.4.50 –Kpic

(Obsolete) Synonym for -pic.

3.4.51 –KPIC

(Obsolete) Synonym for -PIC.

3.4.52 –Lpath

Add path to list of directory paths to search
for libraries.

Adds path to the front of
the list of object–library search directories. A space between -L and path is optional. This option is passed to the linker. See also 3.4.53 –lx.

While building the executable file, ld(1) searches path for archive libraries (.a files)
and shared libraries (.so files). ldsearches path before searching the
default directories. (See the Fortran Programming Guide chapter “Libraries”
for information on library search order.) For the relative order between LD_LIBRARY_PATH and -Lpath,
see ld(1).

Note –

Specifying /usr/lib or /usr/ccs/lib with -Lpath may prevent linking the unbundled libm. These directories
are searched by default.

Example: Use -Lpath to
specify library search directories:

demo% f95 -L./dir1 -L./dir2 any.f

3.4.53 –lx

Add library libx.a to linker’s list of search
libraries.

Pass -lx to the linker to specify additional libraries for ld to
search for unresolved references. ld links with object library libx.
If shared library libx.so is available (and -Bstatic or -dn are not specified), ld uses it, otherwise, ld uses static library libx.a. If it uses a shared library, the name is built in to a.out. No space is allowed between -l and x character strings.

Example: Link with the library libVZY:

demo% f95 any.f -lVZY

Use -lx again to link
with more libraries.

Example: Link with the libraries liby and libz:

demo% f95 any.f -ly -lz

See also the “Libraries” chapter in the Fortran
Programming Guide for information on library search paths and
search order.

3.4.54 –libmil

Inline selected libm library
routines for optimization.

There are inline templates for some of the libm library
routines. This option selects those inline templates that produce the fastest
executable for the floating–point options and platform currently being
used.

For more information, see the man pages libm_single(3F)
and libm_double(3F)

3.4.55 –loopinfo

Show loop parallelization results.

Show which loops were and were not parallelized with
the–autopar option.

3.4.56 –Mpath

Look in path for Fortran 95 modules referenced in the current compilation.
This path is searched in addition to the current directory.

path can specify a directory, .a archive
file of precompiled module files, or a .mod precompiled
module file. The compiler determines the type of the file by examining its
contents.

An archive .a file must be explicitly specified
on a -M option flag to be searched for modules. The
compiler will not search archive files by default.

Only .mod files with the same names as the MODULE names appearing on USE statements
will be searched. For example, the statement USEME causes the compiler to look only for the module file me.mod

When searching for modules, the compiler gives higher priority to the
directory where the module files are being written. This is controlled by
the -moddir compiler option, or the MODDIR environment
variable. When neither are specified, the default write-directory is the current
directory. When both are specified, the write-directory is the path specified
by the -moddir flag.

This means that if only the -M flag appears,
the current directory will be searched for modules first before any object
listed on the -M flag. To emulate the behavior of previous
releases, use:

-moddir=empty-dir -Mdir -M

where empty-dir is the path to an empty directory.

A space between the -M and the path is allowed.
For example, -M /home/siri/PK15/Modules

On Solaris, if the path identifies a regular file that is
not an archive or a module file, the compiler passes the option
to the linker, ld, which will treat it as a
linker mapfile. This feature is provided as a convenience similar
to the C and C++ compilers.

3.4.57 –m32 | –m64

Specify memory model for compiled binary object.

Use -m32 to create 32-bit executables and shared
libraries. Use -m64 to create 64-bit executables and
shared libraries.

The ILP32 memory model (32-bit int, long, pointer data types) is the
default on all Solaris platforms and on Linux platforms that are not 64-bit
enabled. The LP64 memory model (64-bit long, pointer data types) is the default
on Linux platforms that are 64-bit enabled. -m64 is
permitted only on platforms that are enabled for the LP64 model.

Object files or libraries compiled with -m32 cannot
be linked with object files or libraries compiled with -m64.

When compiling applications with large amounts of static data using -m64, -xmodel=medium may also be required.

Be aware that some Linux platforms do not support the medium model.

Note that in previous compiler releases, the memory model, ILP32 or
LP64, was implied by the choice of the instruction set with -xarch.
Starting with the Sun Studio 12 compilers, this is no longer the case. On
most platforms, just adding -m64 to the command line
is sufficient to create 64-bit objects.

On Solaris, -m32 is the default. On Linux systems
supporting 64-bit programs, -m64 -xarch=sse2 is
the default.

3.4.58 –moddir=path

Specify where the compiler will write compiled .mod MODULE
files.

The compiler will write the .mod MODULE information
files it compiles in the directory specified by path.
The directory path can also be specified with the MODDIR environment
variable. If both are specified, this option flag takes precedence.

The compiler uses the current directory as the
default for writing .mod files.

Sun and Cray directives cannot both be active in the same compilation
unit.

A summary of the Sun and Cray parallelization directives appears in Table C–1 in this manual. See the Fortran Programming Guide for details.

3.4.60 –mt

Require linking to thread–safe libraries.

If you do your own low–level thread management (for example,
by calling the libthread library), compiling with -mt prevents conflicts.

Use -mt if you mix Fortran with multithreaded
C code that calls the libthread library. See also the
Solaris Multithreaded Programming Guide.

–mt is implied automatically when using
the -autopar, -explicitpar,
or -parallel options.

Note the following:

A function subprogram that does I/O should not itself be referenced
as part of an I/O statement. Such recursive I/O may cause
the program to deadlock with -mt.

In general, do not compile your own multithreaded
code with -autopar, -explicitpar,
or -parallel. The compiler-generated calls to the threads
library and the program’s own calls may conflict, causing unexpected
results.

On a single–processor system, performance may be degraded
with the -mt option.

3.4.61 –native

(Obsolete) Optimize performance for the host system.

This option is a synonym for -xtarget=native,
which is preferred. The -fast option sets -xtarget=native.

3.4.63 –nodepend

3.4.64 –noexplicitpar

3.4.65 -nofstore

(x86) Cancel -fstore on
command line.

The compiler default is -fstore. -fast includes -nofstore.

3.4.66 –nolib

Disable linking with system libraries.

Do not automatically link with any system
or language library; that is do not pass any default -lx options on to ld.
The normal behavior is to link system libraries into the executables automatically,
without the user specifying them on the command line.

The -nolib option makes it easier to link one
of these libraries statically. The system and language libraries are required
for final execution. It is your responsibility to link them in manually. This
option provides you with complete control.

Link libm statically and libc dynamically
with f95:

demo% f95 -nolib any.f95 -Bstatic -lm -Bdynamic -lc

The order for the -lx options
is important. Follow the order shown in the examples.

3.4.67 –nolibmil

Cancel -libmil on command line.

Use this option after the -fast option
to disable inlining of libm math routines:

demo% f95 -fast -nolibmil …

3.4.68 –noreduction

Disable -reduction on command line.

This option disables -reduction.

3.4.69 –norunpath

Do not build a runtime shared library search path into the executable.

The compiler normally builds into an
executable a path that tells the runtime linker where to find the shared libraries
it will need. The path is installation dependent. The -norunpath option
prevents that path from being built in to the executable.

This option is helpful when libraries have been installed in some nonstandard
location, and you do not wish to make the loader search down those paths when
the executable is run at another site. Compare with -Rpaths.

See the Fortran Programming Guide chapter on “Libraries”
for more information.

3.4.70 –O[n]

Specify optimization level.

n can be 1, 2, 3, 4, or 5. No space
is allowed between -O and n.

If -O[n] is not specified, only a very basic level of optimization limited
to local common subexpression elimination and dead code analysis is performed.
A program’s performance may be significantly improved when compiled
with an optimization level than without optimization. Use of -O (which
sets -O3) or -fast (which sets -O5) is recommended for most programs.

Each -On level includes
the optimizations performed at the levels below it. Generally, the higher
the level of optimization a program is compiled with, the better runtime performance
obtained. However, higher optimization levels may result in increased compilation
time and larger executable files.

Debugging with -g does
not suppress -On, but -On limits -g in
certain ways; see the dbx documentation.

The -O3 and -O4 options
reduce the utility of debugging such that you cannot display variables from dbx, but you can still use the dbxwhere command to get a symbolic traceback.

If the optimizer runs out of memory, it attempts to proceed over again
at a lower level of optimization, resuming compilation of subsequent routines
at the original level.

For details on optimization, see the Fortran Programming
Guide chapters “Performance Profiling” and “Performance
and Optimization.”

3.4.71 –O

This is equivalent to -O3.

3.4.72 –O1

Provides a minimum of statement–level optimizations.

Use if higher levels result in excessive compilation time, or exceed
available swap space.

3.4.73 –O2

Enables basic block level optimizations.

This level usually gives the smallest code size. (See also -xspace.)

–O3 is preferred over -O2 unless -O3 results in unreasonably long compilation time, exceeds swap
space, or generates excessively large executable files.

3.4.75 –O4

The -g option suppresses the -O4 automatic
inlining described above.–xcrossfile increases
the scope of inlining with -O4.

3.4.76 –O5

Attempt aggressive optimizations.

Suitable only for that small fraction of a program that uses the largest
fraction of compute time. -O5’s optimization
algorithms take more compilation time, and may also degrade performance when
applied to too large a fraction of the source program.

Optimization at this level is more likely to improve performance if
done with profile feedback. See -xprofile=p.

3.4.77 –oname

Specify the name of the executable file to be written.

There must be a blank between -o and name. Without this option, the default is to write
the executable file to a.out. When used with -c, -o specifies the target .o object
file; with -G it specifies the target .so library
file.

3.4.78 –onetrip

Enable one trip DO loops.

Compile DO loops so that they are executed
at least once. DO loops in standard Fortran are not
performed at all if the upper limit is smaller than the lower limit, unlike
some legacy implementations of Fortran.

3.4.79 –openmp

Synonym for -xopenmp.

3.4.80 –p

(Obsolete) Compile for profiling with the prof profiler.

Prepare object files for profiling, see prof (1).
If you compile and link in separate steps, and also compile with the -p option, then be sure to link with the -p option. -p with prof is provided mostly for compatibility
with older systems. -pg profiling with gprof is
possibly a better alternative. See the Fortran Programming Guide chapter
on Performance Profiling for details.

3.4.81 –pad[=p]

Insert padding for efficient use of cache.

This option
inserts padding between arrays or character variables, if they are static
local and not initialized, or if they are in common blocks. The extra padding
positions the data to make better use of cache. In either case, the arrays
or character variables can not be equivalenced.

p, if present, must be either %none or
either (or both) local or common:

local

Add padding between adjacent local variables.

common

Add padding between variables in common blocks.

%none

Do not add padding. (Compiler default.)

If both local and common are
specified, they can appear in any order.

Defaults for -pad:

The compiler does no padding by default.

Specifying -pad, but without a value
is equivalent to -pad=local,common.

The -pad[=p] option
applies to items that satisfy the following criteria:

If -pad=common is specified for compiling
a file that references a common block, it must be specified when compiling
all files that reference that common block. The option changes the spacing
of variables within the common block. If one program unit is compiled with
the option and another is not, references to what should be the same location
within the common block might reference different locations.

If -pad=common is specified, the declarations
of common block variables in different program units must be the same except
for the names of the variables.The amount of padding inserted between variables
in a common block depends on the declarations of those variables. If the variables
differ in size or rank in different program units, even within the same file,
the locations of the variables might not be the same.

If -pad=common is specified, EQUIVALENCE declarations involving common block variables are flagged with
a warning message and the block is not padded.

Avoid overindexing arrays in common blocks with -pad=common specified. The altered positioning of adjacent data in a padded
common block will cause overindexing to fail in unpredictable ways.

It is the programmer’s responsibility to make sure that common
blocks are compiled consistently when -pad is used.
Common blocks appearing in different program units that are compiled inconsistently
with -pad=common will cause errors. Compiling with -Xlist will report when common blocks with the same name have
different lengths in different program units.

3.4.82 –parallel

(Obsolete, SPARC)
Parallelize with: -autopar, -explicitpar, -depend

Note –

This option includes -explicitpar which
enables legacy Sun and Cray parallelization directives. These directives are
now deprecated and no longer supported. The OpenMP API is the preferred and
supported parallelization model with Sun Studio compilers. See the Sun
Studio OpenMP API User’s Guide for details on migrating
legacy Sun/Cray directives to OpenMP.

Parallelize loops chosen automatically by the compiler as well as explicitly
specified by user supplied directives. Optimization level is automatically
raised to -O3 if it is lower. See also 3.4.23 –explicitpar.

To improve performance, also specify the -stackvar option
when using any of the parallelization options, including -autopar.

Sun-style parallelization directives are enabled by default. Use -mp=cray to select Cray style parallelization directives. (Note:
For OpenMP parallelization use -xopenmp, not -parallel.)

Parallelization options like -parallel are intended
to produce executable programs to be run on multiprocessor systems. On a single–processor
system, parallelization generally degrades performance.

To run a parallelized program in a multithreaded environment, you must
set the PARALLEL (or OMP_NUM_THREADS)
environment variable prior to execution. This tells the runtime system the
maximum number of threads the program can create. The default is 1. In general,
set the PARALLEL or OMP_NUM_THREADS variable
to the number of available virtual processors on the target platform. (See psrinfo(1))

If you use -parallel and compile and link in one step, then linking
automatically includes the multithreading library and the thread–safe
Fortran runtime library. If you use -parallel and compile
and link in separate steps, then you must also link with -parallel.

See the Fortran Programming Guide chapter “Parallelization”
for further information.

3.4.83 –pg

Compile for profiling with the gprof profiler.

Compile self–profiling code
in the manner of -p, but invoke a runtime recording
mechanism that keeps more extensive statistics and produces a gmon.out file when the program terminates normally. Generate an execution
profile by running gprof. See the gprof(1)
man page and the Fortran Programming Guide for details.

Library options must be after the source and .o files (–pg libraries are static).

Note –

There is no advantage compiling with -xprofile if
you specify -pg. These two features do not prepare
or use data provided by the other.

Profiles generated by using prof(1) or gprof(1) on 64 bit Solaris platforms or just gprof on
32 bit Solaris platforms include approximate user CPU times. These times are
derived from PC sample data (see pcsample(2)) for routines
in the main executable and routines in shared libraries specified as linker
arguments when the executable is linked. Other shared libraries (libraries
opened after process startup using dlopen(3DL)) are
not profiled.

On 32 bit Solaris systems, profiles generated using prof(1)
are limited to routines in the executable. 32 bit shared libraries can be
profiled by linking the executable with -pg and using gprof(1).

The Solaris 10 software does not include system libraries compiled with -p. As a result, profiles collected on Solaris 10 platforms do
not include call counts for system library routines.

The compiler options -p,-pg,
or -xpg should not be used to compile multi-threaded
programs, because the runtime support for these options is not thread-safe.
If a program that uses multiple threads is compiled with these options invalid
results or a segmentation fault could occur at runtime.

If you compile and link in separate steps, and you compile with -pg, then be sure to link with -pg.

3.4.84 –pic

Compile position–independent code for shared library.

On SPARC, –pic is equivalent to -xcode=pic13. See 3.4.122 –xcode=keyword for
more information on position-indepented code.

On x86, produces position-independent code. Use this option to compile
source files when building a shared library. Each reference to a global datum
is generated as a dereference of a pointer in the global offset table. Each
function call is generated in pc-relative addressing mode through a procedure
linkage table.

3.4.85 –PIC

Compile position–independent code with 32-bit addresses.

On SPARC, –PIC is equivalent to -xcode=pic32. See 3.4.122 –xcode=keyword for
more information about position-independent code.

On x86, —PIC is equivalent to —pic.

3.4.86 –Qoptionpr ls

Pass the suboption list ls to the compilation
phase pr.

There must be blanks separating Qoption, pr, and ls.
The Q can be uppercase or lowercase. The list is a
comma–delimited list of suboptions, with no blanks within the list.
Each suboption must be appropriate for that program phase, and can begin with
a minus sign.

This option is provided primarily for debugging the internals of the
compiler by support staff. Use the LD_OPTIONS environment
variable to pass options to the linker. See the chapter on linking and libraries
in the Fortran Programming Guide.

3.4.87 –qp

Synonym for -p.

3.4.88 –Rls

Build dynamic library search paths into the executable file.

With this
option, the linker, ld(1), stores a list of dynamic
library search paths into the executable file.

ls is a colon–separated list of directories
for library search paths. The blank between -R and ls is optional.

Multiple instances of this option are concatenated together, with each
list separated by a colon.

The list is used at runtime by the runtime linker, ld.so.
At runtime, dynamic libraries in the listed paths are scanned to satisfy any
unresolved references.

Use this option to let users run shippable executables without a special path option to find needed dynamic
libraries.

Building an executable file using -Rpaths adds directory paths to a default path, /opt/SUNWspro/lib, that is always searched last.

For more information, see the “Libraries” chapter in the Fortran Programming Guide, and the Solaris Linker
and Libraries Guide.

3.4.89 –r8const

Promote single-precision constants to REAL*8 constants.

All single-precision REAL constants are promoted
to REAL*8. Double-precision (REAL*8)
constants are not changed. This option only applies to constants. To promote
both constants and variables, see 3.4.179 –xtypemap=spec.

Use this option flag carefully. It could cause interface problems when
a subroutine or function expecting a REAL*4 argument
is called with a REAL*4 constant that gets promoted
to REAL*8. It could also cause problems with programs
reading unformatted data files written by an unformatted write with REAL*4 constants on the I/O list.

3.4.90 –reduction

Recognize reduction operations in loops.

Analyze loops for reduction operations during automatic parallelization. There is potential for roundoff error with the
reduction.

A reduction operation accumulates the elements
of an array into a single scalar value. For example, summing the elements
of a vector is a typical reduction operation. Although these operations violate
the criteria for parallelizability, the compiler can recognize them and parallelize
them as special cases when -reduction is specified.
See the Fortran Programming Guide chapter “Parallelization”
for information on reduction operations recognized by the compilers.

This option is usable only with the automatic parallelization options -autopar or -parallel. It is ignored otherwise.
Explicitly parallelized loops are not analyzed for reduction operations.

Example: Automatically parallelize with reduction:

demo% f95 -parallel -reduction any.f

3.4.91 –S

Compile and only generate assembly code.

Compile the named
programs and leave the assembly–language output on corresponding files
suffixed with .s. No .o file
is created.

3.4.92 –s

Strip the symbol table out of the executable
file.

This option makes the executable file smaller and more difficult to
reverse engineer. However, this option inhibits debugging with dbx or
other tools, and overrides -g.

3.4.93 –sb

(Obsolete) Produce table information for the source code browser.

Note –

-sb cannot be used on source files the
compiler automatically passes through the fpp or
cpp preprocessors (that is, files with
.F, . F90,
.F95, or .F03 extensions),
or used with the -F option.

3.4.94 –sbfast

(Obsolete) Produce only source code browser
tables.

Produce only table information for the source code
browser. Do not assemble, link, or make object files.

Note –

-sbfast cannot be used on source files
the compiler automatically passes through the fpp or
cpp preprocessors (that is, files with
.F, . F90,
. F95, or .F03 extensions),
or used with the -F option.

3.4.95 –silent

(Obsolete) Suppress compiler messages.

Normally, the f95 compiler
does not issue messages, other than error diagnostics, during compilation.
This option flag is provided for compatibility with the legacy f77 compiler,
and its use is redundant except with the -f77 compatibility
flag.

3.4.96 –stackvar

Allocate local variables on the stack whenever possible.

This option makes writing recursive and re-entrant code easier and provides
the optimizer more freedom when parallelizing loops.

Use of -stackvar is recommended with any of the
parallelization options.

Local variables are variables that are not dummy arguments, COMMON variables, variables inherited from an outer scope, or
module variables made accessible by a USE statement.

With -stackvar in effect, local variables are
allocated on the stack unless they have the attributes SAVE or STATIC. Note that explicitly initialized variables are implicitly
declared with the SAVE attribute. A structure variable
that is not explicitly initialized but some of whose components are initialized
is, by default, not implicitly declared SAVE. Also,
variables equivalenced with variables that have the SAVE or STATIC attribute are implicitly SAVE or STATIC.

A statically allocated variable is implicitly initialized to zero unless
the program explicitly specifies an initial value for it. Variables allocated
on the stack are not implicitly initialized except that components of structure
variables can be initialized by default.

Putting large arrays onto the stack with -stackvar can overflow
the stack causing segmentation faults. Increasing the stack size may
be required.

The initial thread executing the program has a main stack,
while each helper thread of a multithreaded program has its own thread stack.

The default size of the main stack is about 8 Megabytes. The default
thread stack size is 4 Megabytes on 32–bit systems, 8 Megabytes on 64–bit
systems. The limit command
(with no parameters) shows the current main stack size. If you get a segmentation
fault using -stackvar, try increasing the main and
thread stack sizes.

3.4.97 –stop_status[={yes|no}]

With -stop_status=yes, a STOP statement may contain an integer
constant. That value will be passed to the environment as the program terminates:

STOP 123

The value must be in the range 0 to 255. Larger values are truncated
and a run–time message issued. Note that

STOP ”stop string’

is still accepted and returns a status value of 0 to the environment,
although a compiler warning message will be issued.

The environment status variable is $status for
the C shell csh, and $? for
the Bourne and Korn shells, sh and ksh.

3.4.98 –temp=dir

Define directory for temporary files.

Set directory for temporary files used by the compiler to be dir. No space is allowed within this option string. Without this
option, the files are placed in the /tmp directory.

3.4.99 –time

Time each compilation phase.

The time spent and resources used in each compiler pass is displayed.

3.4.100 –U

Recognize upper and lower case in source files.

Do not treat uppercase letters as equivalent to lowercase. The default
is to treat uppercase as lowercase except within character–string constants.
With this option, the compiler treats Delta, DELTA, and delta as different symbols. Calls
to intrinsic functions are not affected by this option.

Portability and mixing Fortran with other languages may require use
of -U. See the Fortran Programming Guide chapter
on porting programs to Fortran 95.

3.4.101 -Uname

Undefine preprocessor macro name.

This option applies only to source files that invoke
the fpp or cpp pre-processor.
It removes any initial definition of the preprocessor macro name created
by -Dname on the same command
line, including those implicitly placed there by the command-line driver,
regardless of the order the options appear. It has no effect on any macro
definitions in source files. Multiple -Uname flags
can appear on the command line. There must be no space between -U and
the macro name.

3.4.102 –u

Report undeclared variables.

Make the default type for all variables be undeclared rather than using Fortran implicit typing, as if IMPLICITNONE appeared in each compilation unit. This option warns of undeclared
variables, and does not override any IMPLICIT statements
or explicit type statements.

3.4.103 –unroll=n

Enable unrolling of DO loops where possible.

n is a positive integer. The choices are:

n=1 inhibits all loop unrolling.

n>1 suggests to
the optimizer that it attempt to unroll loops n times.

Loop unrolling generally
improves performance, but will increase the size of the executable file. For
more information on this and other compiler optimizations, see the “Performance
and Optimization” chapter in the Fortran Programming Guide.
See also 2.3.1.3 The UNROLL Directive.

3.4.104 –use=list

Specify implicit USE modules.

list is a comma-separated list of module
names or module file names.

Compiling with -use=module_name has
the effect of adding a USEmodule_name statement
to each subprogram or module being compiled. Compiling with -use=module_file_name has the effect of adding a USEmodule_name for each of the modules contained in the specified
file.

Use with -xopenmp and OpenMP API directives,
or with -explicitpar and C$MIC DOALL legacy
parallelization directives.

Warnings are issued with the compiler detects the following situations:

Problematic use of OpenMP data sharing attributes clauses,
such as declaring a variable shared whose accesses in an OpenMP parallel region
may cause data race, or declaring a variable private whose value in a parallel
region is used after the parallel region.

C$MICDOALL parallelized
loops with data dependencies between different loop iterations.

No warnings appear if all parallelization directives are processed without
issues.

Note –

Sun Studio compilers support the OpenMP API parallelization model.
Consequently, C$MIC parallelization directives are
deprecated. See the OpenMP API User’s Guide for
information on migrating to the OpenMP API.

3.4.109 –w[n]

Show or suppress warning messages.

This option shows or suppresses most warning messages. However, if one
option overrides all or part of an option earlier on the command line, you
do get a warning.

n may be 0, 1, 2 ,3, or 4.

-w0 shows just error messages. This is equivalent
to -w. -w1 shows errors and
warnings. This is the default without -w.-w2 shows
errors, warnings, and cautions.-w3 shows errors, warnings,
cautions, and notes.-w4 shows errors, warnings, cautions,
notes, and comments.

3.4.110 –Xlist[x]

Produce listings and do global program checking (GPC).

Use this
option to find potential programming bugs. It invokes an extra compiler pass
to check for consistency in subprogram call arguments, common blocks, and parameters, across the global program. The option also generates
a line–numbered listing of the source code, including a cross reference table. The error messages issued by the -Xlist options are advisory warnings and do not prevent the program
from being compiled and linked.

Note –

Be sure to correct all syntax errors in the source code before
compiling with -Xlist. Unpredictable reports may result
when run on a source code with syntax errors.

Example: Check across routines for consistency:

demo% f95 -Xlist fil.f

The above example writes the following to the output file fil.lst:

A line–numbered source listing (default)

Error messages (embedded in the listing) for inconsistencies
across routines

A cross reference table of the identifiers (default)

By default, the listings are written to the file name.lst,
where name is taken from the first listed source file
on the command line.

A number of sub–options provide further flexibility in the selection
of actions. These are specified by suffixes to the main -Xlist option,
as shown in the following table

Table 3–9 –Xlist Suboptions

Option

Feature

–Xlist

Show errors, listing, and cross reference table

–Xlistc

Show call graphs and errors

–XlistE

Show errors

–Xlisterr[nnn]

Suppress error nnn messages

–Xlistf

Show errors, listing, and cross references, but no object files

–Xlisth

Terminate compilation if errors detected

–XlistI

Analyze #include and INCLUDE files
as well as source files

–XlistL

Show listing and errors only

–Xlistln

Set page length to n lines

-XlistMP

Check OpenMP directives (SPARC)

–Xlistoname

Output report file to name instead of file.lst

–Xlists

Suppress unreferenced names from the cross–reference table

–Xlistvn

Set checking level to n (1,2,3, or 4) -default
is 2

–Xlistw[nnn]

Set width of output line to nnn columns -default
is 79

–Xlistwar[nnn]

Suppress warning nnn messages

–XlistX

Show cross–reference table and errors

See the Fortran Programming Guide chapter “Program
Analysis and Debugging” for details.

3.4.111 –xa

Synonym for -a.

3.4.112 –xalias[=keywords]

Specify degree of aliasing to be assumed by the compiler.

Some non-standard programming techniques can introduce situations
that interfere with the compiler’s optimization strategies. The use
of overindexing, pointers,
and passing global or non-unique variables as subprogram arguments, can introduce
ambiguous aliasing situations that could result code that does not work as
expected.

Use the -xalias flag to inform the compiler about
the degree to which the program deviates from the aliasing requirements of
the Fortran standard.

The flag may appear with or without a list of keywords. The keywords list is comma-separated, and each keyword indicates an aliasing
situation present in the program.

Each keyword may be prefixed by no% to indicate
an aliasing type that is not present.

The aliasing keywords are:

Table 3–10 -xalias Option Keywords

keyword

meaning

dummy

Dummy (formal) subprogram parameters can alias each other and global
variables.

no%dummy

(Default). Usage of dummy parameters follows the Fortran standard and
do not alias each other or global variables.

craypointer

(Default). Cray pointers can point at any global variable or a local
variable whose address is taken by the LOC() function.
Also, two Cray pointers might point at the same data. This is a safe assumption
that could inhibit some optimizations.

no%craypointer

Cray pointers point only at unique memory addresses, such as obtained
from malloc(). Also, no two Cray pointers point at
the same data. This assumption enables the compiler to optimize Cray pointer
references.

actual

The compiler treats actual subprogram arguments as if they were global
variables. Passing an argument to a subprogram might result in aliasing through
Cray pointers.

no%actual

(Default) Passing an argument does not result in further aliasing.

overindex

A reference to an element in a COMMON block might refer to
any element in a COMMON block or equivalence group.

Passing any element of a COMMON block or equivalence group
as an actual argument to a subprogram gives access to any element of that
COMMON block or equivalence group to the called subprogram.

Variables of a sequence derived type are treated as if they
were COMMON blocks, and elements of such a variable might alias other elements
of that variable.

Individual array bounds may be violated, but except as noted
above, the referenced array element is assumed to stay within the array. Array
syntax, WHERE, and FORALL statements
are not considered for overindexing. If overindexing occurs in these constructs,
they should be rewritten as DO loops.

no%overindex

(Default) Array bounds are not violated. Array references do not reference
other variables.

ftnpointer

Calls to external functions might cause Fortran pointers to point at
target variables of any type, kind, or rank.

no%ftnpointer

(Default) Fortran pointers follow the rules of the standard.

Specifying -xalias without a list gives the best
performance for most programs that do not violate Fortran aliasing rules,
and corresponds to:

no%dummy,no%craypointer,no%actual,no%overindex,no%ftnpointer

To be effective, -xalias should be used when
compiling with optimization levels -xO3 and higher.

The compiler default, with no -xalias flag specified,
assumes that the program conforms to the Fortran 95 standard except for Cray
pointers:

no%dummy,craypointer,no%actual,no%overindex,no%ftnpointer

Examples of various aliasing situations and how to specify them with -xalias are given in the Porting chapter of the Fortran
Programming Guide.

3.4.113 –xarch=isa

Specify instruction set architecture (ISA).

Architectures that are accepted by -xarch keyword isa are shown in Table 3–11:

Note that although -xarch can be used alone,
it is part of the expansion of the –xtarget option
and may be used to override the -xarch value that is
set by a specific -xtarget option. For example:

% f95 -xtarget=ultra2 -xarch=sparcfmaf ...

overrides the -xarch set by -xtarget=ultra2

This option limits the code generated by the compiler to the instructions
of the specified instruction set architecture by allowing only the specified
set of instructions. This option does not guarantee use of any target–specific
instructions.

If this option is used with optimization, the appropriate choice can
provide good performance of the executable on the specified architecture.
An inappropriate choice results in a binary program that is not executable
on the intended target platform.

Object binary files (.o) compiled with sparc and sparcvis can be linked and can
execute together, but will run only on a sparcvis—compatible
platform.

Object binary files (.o) compiled with sparc, sparcvis, and sparcvis2 can
be linked and can execute together, but will run only on a sparcvis2–compatible platform.

For any particular choice, the generated executable may run much more
slowly on earlier architectures. Also, although quad-precision (REAL*16 and longdouble)
floating-point instructions are available in many of these instruction set
architectures, the compiler does not use these instructions in the code it
generates.

The default when -xarch is not specified is sparc on SPARC platforms, 386 on x86 platforms.

Table 3–12 gives details
for each of the -xarch keywords on SPARC platforms.

Table 3–12 -xarch Values for SPARC Platforms

-xarch=

Meaning (SPARC)

generic

Compile using the instruction set common to
most processors.

generic64

Compile for most 64–bit platforms.

(Solaris only) This option is equivalent to -m64 -xarch=generic
and is provided for compatibility with earlier releases.
Use -m64 to specify 64-bit compilation
instead of -xarch=generic64

native

Compile for good performance on this system.

The compiler chooses the appropriate setting for the current system
processor it is running on. This is the default for the -fast option.

native64

Compile for good performance in 64-bit mode
on this system.

(Solaris only) This option is equivalent to -m64 -xarch=native and is provided for compatibility
with earlier releases.

sparc

Compile for the SPARC–V9 ISA.

Compile for the V9 ISA, but without the Visual Instruction
Set (VIS), and without other implementation-specific ISA
extensions. This option enables the compiler to generate
code for good performance on the V9 ISA.

sparcvis

Compile for the SPARC–V9 ISA with UltraSPARC
extensions.

Compile for SPARC-V9 plus the Visual Instruction
Set (VIS) version 1.0, and with UltraSPARC extensions.
This option enables the compiler to generate code for
good performance on the UltraSPARC architecture.

sparcvis2

Compile for the SPARC-V9 ISA with UltraSPARC-III
extensions.

Enables the compiler to generate object code for
the UltraSPARC architecture, plus the Visual Instruction
Set (VIS) version 2.0, and with UltraSPARC III extensions.

sparcfmaf

Compile for the sparcfmaf version of the SPARC-V9 ISA.

Enables the compiler to use instructions from the SPARC-V9 instruction
set, plus the UltraSPARC extensions, including the Visual Instruction Set
(VIS) version 1.0, the UltraSPARC-III extensions, including the Visual Instruction
Set (VIS) version 2.0, and the SPARC64 VI extensions for floating-point multiply-add.

Note that you must use -xarch=sparcfmafin conjunction
with -fma=fused and some optimization level to get
the compiler to attempt to find opportunities to use the multiply-add instructions
automatically.

v9

Equivalent to -m64 -xarch=sparc Legacy
makefiles and scripts that use -xarch=v9 to obtain
the 64-bit memory model need only use -m64.

v9a

Equivalent to -m64 -xarch=sparcvis and is provided
for compatibility with earlier releases.

v9b

Equivalent to -m64 -xarch=sparcvis2 and is provided
for compatibility with earlier releases.

Table 3–13 details each
of the -xarch keywords on x86 platforms. The default
on x86 is generic if -xarch is
not specified.

Table 3–13 -xarch Values for x86 Platforms

-xarch=

Meaning (x86)

generic

Compile for good performance on most 32-bit x86 platforms. This is the
default, and is equivalent to -xarch=386.

generic64

Compile for good performance on most 64-bit x86 platforms. It is interpreted
as amd64 currently.

native

Compile for good performance on this x86 architecture. Use the best
instruction set for good performance on most x86 processors. With each new
release, the definition of “best” instruction set may be adjusted,
if appropriate.

If you compile and link in separate steps, always link using
the compiler and with same -xarch setting to ensure
that the correct startup routine is linked.

Arithmetic results on x86 may differ from results on SPARC
due to the x86 80-byte floating-point registers. To minimize these differences,
use the -fstore option or compile with -xarch=sse2 if the hardware supports SSE2.

Starting with Sun Studio 11 and the Solaris 10 OS, program
binaries compiled and built using these specialized -xarch hardware
flags are verified that they are being run on the appropriate platform.

On systems prior to Solaris 10, no verification is done and
it is the user’s responsibility to ensure objects built using these
flags are deployed on suitable hardware.

Running programs compiled with these -xarch options
on platforms that are not enabled with the appropriate features or instruction
set extensions could result in segmentation faults or incorrect results occurring
without any explicit warning messages.

3.4.114 –xassume_control[=keywords]

Set parameters to control ASSUME pragmas.

Use this flag to control the way the compiler
handles ASSUME pragmas in the source code.

The ASSUME pragmas provide a way for the programmer
to assert special information that the compiler can use for better optimization.
These assertions may be qualified with a probability value. Those with a probability
of 0 or 1 are marked as certain; otherwise they are considered non-certain.

You can also assert, with a probability or certainty, the trip count
of an upcoming DO loop, or that an upcoming branch will be taken.

The keywords on the -xassume_control option
can be a single suboption keyword or a comma-separated list of keywords. The
keyword suboptions recognized are:

optimize

The assertions made on ASSUME pragmas affect
optimization of the program.

check

The compiler generates code to check the correctness of all assertions
marked as certain, and emits a runtime message if the assertion is violated;
the program continues if fatal is not also specified.

fatal

When used with check, the program will terminate
when an assertion marked certain is violated.

retrospective[:d]

The d parameter is an optional tolerance
value, and must be a real positive constant less than 1. The default is ".1". retrospective compiles code to count the truth or falsity of all
assertions. Those outside the tolerance value d are
listed on output at program termination.

%none

All ASSUME pragmas are ignored.

The compiler default is

-xassume_control=optimize

This means that the compiler recognizes ASSUME pragmas
and they will affect optimization, but no checking is done.

If specified without parameters, -xassume_control implies

-xassume_control=check,fatal

In this case the compiler accepts and checks all certain ASSUME pragmas,
but they do not affect optimization. Assertions that are invalid cause the
program to terminate.

3.4.115 –xautopar

Synonym for -autopar.

3.4.116 –xbinopt={prepare | off}

(SPARC) Prepare binary for post-compilation
optimization.

The compiled binary file is enabled for later optimizations, transformations,
and analysis by binopt(1). This option may be used
when building executables or shared objects, and it must be used with an optimization
level of -O1 or higher to be effective.

There will be a modest increase in the size of the binary file when
built with this option, on the order of 5%.

If you compile and link in separate steps, -xbinopt must
appear on both the compile and link steps.

If not all the source code for an application is compiled with -xbinopt, the -xbinopt flag should still appear
on the final link step that builds the program binary, as shown below:

example% f95 -0 program -xbinopt=prepare a.o b.o c.f95

Only code compiled with -xbinopt can be optimized
by binopt(1).

The default is -xbinopt=off.

3.4.117 –xcache=c

Define cache properties for the optimizer.

c must be one of the following:

generic

native

s1/l1/a1[/t1]

s1/l1/a1[/t1]:s2/l2/a2[/t2]

s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]

The si/li/ai/ti are defined as follows:

si The size of the data cache at level i, in kilobytesli The line size of
the data cache at level i, in bytesai The
associativity of the data cache at level iti The number of hardware threads sharing the cache at level i(optional).

This option specifies the cache properties that the optimizer can use.
It does not guarantee that any particular cache property is used.

Although this option can be used alone, it is part of the expansion
of the–xtarget option; it is provided to allow
overriding an -xcache value implied by a specific -xtarget option.

Table 3–14 –xcache Values

Value

Meaning

generic

Define the cache properties for good performance on most processors
without any major performance degradation. This is the default.

native

Define the cache properties for good performance on this host platform.

3.4.119 –xcg92

3.4.120 –xcheck=keyword

Turn on runtime checking for stack overflow on subprogram entry. If
a stack overflow is
detected, a SIGSEGV segment fault will be raised. (SPARC only)

no%stkovf

Disable runtime checking for stack overflow. (SPARC only)

init_local

Perform special initialization of local variables.

The compiler initializes local variables to a value that is likely to
cause an arithmetic exception if it is used by the program before it is assigned.
Memory allocated by the ALLOCATE statement will also
be initialized in this manner.

Module variables, SAVE variables, and variables
in COMMON blocks are not initialized.

no%init_local

Disable local variable initialization. This is the default.

%all

Turn on all these runtime checking features.

%none

Disable all these runtime checking features.

Stack overflows, especially in multithreaded applications with large
arrays allocated on the stack, can cause silent data corruption in neighboring
thread stacks. Compile all routines with -xcheck=stkovf if
stack overflow is suspected. But note that compiling with this flag does not
guarantee that all stack overflow situations will be detected since they could
occur in routines not compiled with this flag.

3.4.121 –xchip=c

Specify target processor for the optimizer.

This option specifies timing properties by specifying
the target processor.

Although this option can be used alone, it is part of the expansion
of the–xtarget option; it is provided to allow
overriding a -xchip value implied by the a specific -xtarget option.

3.4.122.1 Position-Independent Code:

Use -xcode=pic13 or -xcode=pic32 when
creating dynamic shared libraries to improve runtime performance.

While the code within a dynamic executable is usually tied to a fixed
address in memory, position-independent code can be loaded anywhere in the
address space of the process.

When you use position-independent code, relocatable references are generated
as an indirect reference through a global offset table. Frequently accessed
items in a shared object will benefit from compiling with -xcode=pic13 or -xcode=pic32 by not requiring the large
number of relocations imposed by code that is not position-independent.

The size of the global offset table is limited to 8Kb.

There are two nominal performance costs with -xcode={pic13|pic32} :

A routine compiled with either -xcode=pic13 or -xcode=pic32 executes a few extra instructions upon entry to set
a register to point at the global offset table used for accessing a shared
library’s global or static variables.

Each access to a global or static variable involves an extra
indirect memory reference through the global offset table. If the compile
is done with pic32, there are two additional instructions
per global and static memory reference.

When considering the above costs, remember that the use of -xcode=pic13 or -xcode=pic32 can significantly reduce
system memory requirements, due to the effect of library code sharing. Every
page of code in a shared library compiled -xcode=pic13 or -xcode=pic32 can be shared by every process that uses the library.
If a page of code in a shared library contains even a single non-pic (that
is, absolute) memory reference, the page becomes nonsharable, and a copy of
the page must be created each time a program using the library is executed.

The easiest way to tell whether or not a .o file
has been compiled with -xcode=pic13 or -xcode=pic32 is with the nm command:

nm file.o | grep _GLOBAL_OFFSET_TABLE_

A .o file containing position-independent code
will contain an unresolved external reference to _GLOBAL_OFFSET_TABLE_ as marked by the letter U.

To determine whether to use -xcode=pic13 or -xcode=pic32, check the size of the Global Offset Table (GOT)
by using elfdump-c (see the elfdump(1) man page for more information) and for the section
header, sh_name: .got. The sh_size value
is the size of the GOT. If the GOT is less than 8,192 bytes, specify -xcode=pic13, otherwise specify -xcode=pic32.

In general, use the following guidelines to determine how you should
use -xcode:

If you are building an executable you should not use -xcode=pic13 or -xcode=pic32.

If you are building an archive library only for linking into
executables you should not use -xcode=pic13 or -xcode=pic32.

If you are building a shared library, start with -xcode=pic13 and once the GOT size exceed 8,192 bytes, use -xcode=pic32.

If you are building an archive library for linking into shared
libraries you should just use -xcode=pic32.

Compiling with the -xcode=pic13 or pic32 (or -pic or -PIC) options is recommended when
building dynamic libraries. See the Solaris Linker and Libraries Guide.

3.4.123 –xcommonchk[={yes|no}]

Enable runtime checking of common block inconsistencies.

This option provides a debug check for common block inconsistencies
in programs using TASKCOMMON and
parallelization. (See the discussion of the TASKCOMMON directive in the “Parallelization” chapter
in the Fortran Programming Guide.)

The default is -xcommonchk=no; runtime checking
for common block inconsistencies is disabled because it will degrade performance.
Use -xcommonchk=yes only during program development
and debugging, and not for production-quality programs.

Compiling with -xcommonchk=yes enables runtime
checking. If a common block declared in one source program unit as a regular
common block appears somewhere else on a TASKCOMMON directive, the program will stop with an error message indicating
the first such inconsistency. -xcommonchk without a
value is equivalent to -xcommonchk=yes.

3.4.124 –xcrossfile[={1|0}]

Enable optimization and inlining across source files.

Normally, the scope of the compiler’s analysis is limited to each
separate file on the command line. For example, -O4’s
automatic inlining is limited to subprograms defined and referenced within
the same source file.

With -xcrossfile, the compiler analyzes all the
files named on the command line as if they had been concatenated into a single
source file.

–xcrossfile is only effective when used
with -O4 or -O5.

Cross–file inlining creates a possible source file interdependence
that would not normally be there. If any file in a set of files compiled together
with -xcrossfile is changed, then all files must be
recompiled to insure that the new code is properly inlined. See 3.4.48 –inline=[%auto][[,][no%]f1,…[no%]fn].

The default, without -xcrossfile on the command
line, is -xcrossfile=0, and no cross-file optimizations
are performed. To enable cross-file optimizations, specify -xcrossfile (equivalent to -xcrossfile=1).

Any .s assmbler source files in the compilation
do not participate in the crossfile analysis. Also, the -xcrossfile flag
is ignored if compiling with -S.

3.4.125 –xdebugformat={dwarf|stabs}

Sun Studio compilers are migrating the format of debugger information
from the "stabs" format to the "dwarf" format. The default setting for this
release is -xdebugformat=dwarf.

If you maintain software which reads debugging information, you now
have the option to transition your tools from the stabs format to the dwarf
format.

Use this option as a way of accessing the new format for the purpose
of porting tools. There is no need to use this option unless you maintain
software which reads debugger information, or unless a specific tool tells
you that it requires debugger information in one of these formats.

If you do not specify -xdebugformat, the compiler
assumes -xdebugformat=dwarf. It is an error to specify
the option without an argument.

This option affects the format of the data that is recorded with the -g option. Some the format of that information is also controlled
with this option. So -xdebugformat has a an effect
even when -g is not used.

The dbx and Performance Analyzer software understand both stabs and
dwarf format so using this option does not have any effect on the functionality
of either tool.

This is a transitional interface so expect it to change in incompatible
ways from release to release, even in a minor release. The details of any
specific fields or values in either stabs or dwarf are also evolving.

Use the dwarfdump(1) command to determine the
format of the debugging information in a compiled object or executable file.

3.4.126 –xdepend

Synonym for -depend.

3.4.127 –xexplicitpar

Synonym for -explicitpar.

3.4.128 –xF

Allow function–level reordering by the Performance Analyzer.

Allow the reordering of functions (subprograms) in the core image using
the compiler, the performance analyzer and the linker. If you compile with the -xF option, then run the analyzer, you can generate a map file
that optimizes the ordering of the functions in memory depending on how they are
used together. A subsequent link to build the executable file can be directed
to use that map by using the linker -Mmapfile option. It places each function
from the executable file into a separate section. (The f95 —Mpath option also passes a regular file to the linker; see the
description of the f95 —Mpath option.)

Reordering the subprograms in memory is useful only when the application
text page fault time is consuming a large percentage of the application time.
Otherwise, reordering may not improve the overall performance of the application.
See the Program Performance Analysis Tools manual for
further information on the analyzer.

3.4.129 –xfilebyteorder=options

Support file sharing between little-endian and big-endian platforms.

The flag identifies the byte-order and byte-alignment of data on unformatted
I/O files. options must specify any combination
of the following, but at least one specification must be present:

3.4.129.1 Examples:

3.4.129.2 Notes:

This option does not apply to files opened with STATUS="SCRATCH". I/O operations done on these files are always with the byte-order
and byte-alignment of the native processor.

The first default, when -xfilebyteorder does
not appear on the command line, is -xfilebyteorder=native:%all.

A file name or unit number can be declared only once in this option.

When -xfilebyteorder does appear on the command
line, it must appear with at least one of the little, big, or native specifications.

Files not explicitly declared by this flag are assumed to be native
files. For example, compiling with -xfilebyteorder=little4:zork.out declares zork.out to be a little-endian 32-bit x86 file with a 4-byte maximum
data alignment. All other files in the program are native files.

When the byte-order specified for a file is the same as the native processor
but a different alignment is specified, the appropriate padding will be used
even though no byte swapping is done. For example, this would be the case
when compiling with -m64 for 64-bit x86 platforms and -xfilebyteorder=little4:filename is
specified.

The declared types in data records shared between big-endian and little-endian
platforms must have the same sizes. For example, a file produced by a SPARC
executable compiled with -xtypemap=integer:64,real:64,double:128 cannot
be read by an x86 executable compiled with -xtypemap=integer:64,real:64,double:64 since the default double precision data types will have different
sizes.

Note that unformatted files containing REAL*16 data
cannot be used on x86 platforms, which do not support REAL*16.

An I/O operation with an entire UNION/MAP data
object on a file specified as non-native will result in a runtime I/O error.
You can only execute I/O operations using the individual members of the MAP (and not an entire VAX record containing the UNION/MAP) on non-native files.

3.4.130 –xhasc[={yes|no}]

Treat Hollerith constant as a character string in an actual argument
list.

With -xhasc=yes, the compiler treats Hollerith
constants as character strings when they appear as an actual argument on a
subroutine or function call. This is the default, and complies with the Fortran
standard. (The actual call list generated by the compiler contains hidden
string lengths for each character string.)

With -xhasc=no, Hollerith constants are treated
as typeless values in subprogram calls, and only their addresses are put on
the actual argument list. (No string length is generated on the actual call
list passed to the subprogram.)

Compile routines with -xhasc=no if they call
a subprogram with a Hollerith constant and the called subprogram expects that
argument as INTEGER (or anything other than CHARACTER).

3.4.131 –xhelp={readme|flags}

3.4.132 –xhwcprof[={enable | disable}]

(SPARC) Enable compiler support for dataspace profiling.

With -xhwcprof enabled, the compiler
generates information that helps tools associate profiled load
and store instructions with the data-types and structure
members (in conjunction with symbolic information produced with -g) to which they refer. It associates profile data
with the data space of the target, rather than the instruction space,
and provides insight into behavior that is not easily obtained from
only instruction profiling.

While you can compile a specified set of object files with -xhwcprof, this option is most useful when applied to
all object files in the application. This will provide coverage
to identify and correlate all memory references distributed in the
application's object files.

If you are compiling and linking in separate steps, use -xhwcprof at link time as well.

An instance of -xhwcprof=enable or -xhwcprof=disable overrides all previous instances of -xhwcprof in
the same command line.

-xhwcprof is disabled by default. Specifying -xhwcprof without any arguments is the equivalent to
-xhwcprof=enable.

-xhwcprof requires that optimization be turned
on and that the debug data format be set to dwarf (-xdebugformat=dwarf), which is the default with this release of
Sun Studio..

The combination of -xhwcprof and -g increases
compiler temporary file storage requirements by more than the
sum of the increases due to -xhwcprof and -g specified alone.

The following command compiles example.f and
specifies support for hardware counter profiling and symbolic
analysis of data types and structure members using DWARF
symbols:

f95 -c -O -xhwcprof -g example.f

For more information on hardware counter-based profiling,
see the Sun Studio Performance Analyzer manual.

3.4.134 –xinline=list

3.4.135 -xinstrument=[%no]datarace

Specify this option to compile and instrument your program
for analysis by the Thread Analyzer.

(For information on the Thread Analyzer, see tha(1)
for details.)

By compiling with this option you can then use the Performance Analyzer
to run the instrumented program with collect
-r races to create a data-race-detection
experiment. You can run the instrumented code standalone but it
runs more slowly.

Specify -xinstrument=no%datarace to turn off
this feature. This is the default.

-xinstrument must be specified with an argument.

If you compile and link in seperate steps, you must specify -xinstrument=datarace in both the compilation and linking
steps.

This option defines the preprocessor token __THA_NOTIFY. You can specify #ifdef __THA_NOTIFY to guard calls to libtha(3) routines.

This option also sets -g.

3.4.136 –xinterval[={widestneed|strict|no}]

(SPARC) Enable interval arithmetic
extensions.

The optional value can be one of either no, widestneed or strict. The default if not
specified is widestneed.

no

Interval arithmetic extensions not enabled.

widestneed

Promotes all non-interval variables and literals in any mixed-mode expression
to the widest interval data type in the expression.

strict

Prohibits mixed-type or mixed-length interval expressions. All interval
type and length conversions must be explicit.

3.4.137 –xipo[={0|1|2}]

Perform interprocedural optimizations.

Performs whole-program optimizations by invoking an
interprocedural analysis pass. Unlike -xcrossfile, -xipo will perform optimizations across all object files in the
link step, and is not limited to just the source files on the compile command.

-xipo is particularly useful when compiling and
linking large multi-file applications. Object files compiled with this flag
have analysis information compiled within them that enables interprocedural
analysis across source and pre-compiled program files. However, analysis and
optimization is limited to the object files compiled with -xipo,
and does not extend to object files on libraries.

-xipo=0 disables, and -xipo=1 enables,
interprocedural analysis. -xipo=2 adds interprocedural
aliasing analysis and memory allocation and layout optimizations to improve
cache performance. The default is -xipo=0, and if -xipo is specified without a value, -xipo=1 is
used.

When compiling with -xipo=2, there should be
no calls from functions or subroutines compiled without -xipo=2 (for
example, from libraries) to functions or subroutines compiled with -xipo=2.

As an example, if you interpose on the function malloc() and
compile your own version of malloc() with -xipo=2, all the functions that reference malloc() in
any library linked with your code would also have to be compiled with -xipo=2. Since this might not be possible for system libraries,
your version of malloc should not be compiled with -xipo=2.

When compiling and linking are performed in separate steps, -xipo must be specified in both steps to be effective.

Example using -xipo in a single compile/link
step:

demo% f95 -xipo -xO4 -o prog part1.f part2.f part3.f

The optimizer performs crossfile inlining across all three source files.
This is done in the final link step, so the compilation of the source files
need not all take place in a single compilation and could be over a number
of separate compilations, each specifying -xipo.

Here interprocedural optimizations will be performed between one.f, two.f and three.f,
and between main.f and four.f,
but not between main.f or four.f and
the routines on mylib.a. (The first compilation may
generate warnings about undefined symbols, but the interprocedural optimizations
will be performed because it is a compile and link step.)

Other important information about -xipo:

requires at least optimization level -xO4

conflicts with -xcrossfile; if used
together will result in a compilation error

Building executables compiled with -xipo using
a parallel make tool can cause problems if object files
used in the build are common to the link steps running in
parallel. Each link step should have its own copy of the object
file being optimized prior to linking.

objects compiled without -xipo can
be linked freely with objects compiled with -xipo.

The -xipo option generates significantly
larger object files due to the additional information needed to perform optimizations
across files. However, this additional information does not become part of
the final executable binary file. Any increase in the size of the executable
program will be due to the additional optimizations performed

In this release, crossfile subprogram inlining is the only
interprocedural optimization performed by -xipo.

.s assembly language files do not participate
in interprocedural analysis.

The -xipo flag is ignored if compiling
with -S.

When Not To Compile With-xipo:

Working with the set of object files in the link step, the compiler
tries to perform whole-program analysis and optimizations. For any function
or subroutine foo() defined in this set of object files,
the compiler makes the following two assumptions:

(1) At runtime, foo() will not be called explicitly
by another routine defined outside this set of object files, and

(2) calls to foo() from any routine in the set
of object files will be not be interposed upon by a different version of foo() defined outside this set of object files.

If assumption (1) is not true for the given application, do not compile
with -xipo=2.If assumption (2) is not true, do not
compile with either -xipo=1 or -xipo=2.

As an example, consider interposing on the function malloc() with
your own source version and compiling with -xipo=2.
Then all the functions in any library that reference malloc() that
are linked with your code would have to also be compiled with -xipo=2 and
their object files would need to participate in the link step. Since this
might not be possible for system libraries, your version of malloc should
not be compiled with -xipo=2.

As another example, suppose that you build a shared library with two
external calls, foo() and bar() inside
two different source files, and bar() calls foo() inside its body. If there is a possibility that the function
call foo() could be interposed at runtime, then compile
neither source file for foo() or bar() with -xipo=1 or -xipo=2. Otherwise, foo() could be inlined into bar(), which could
cause incorrect results when compiled with -xipo.

3.4.138 –xipo_archive[={none|readonly|writeback}]

No processing of archive files is performed. The compiler does not apply
cross-module inlining or other cross-module optimizations
to object files compiled using -xipo and
extracted from an archive library at link time. To do
that, both -xipo and either
-xipo_archive=readonlyor
-xipo_archive=writeback must be specified at
link time.

readonly

The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a)
before producing an executable.

The option -xipo_archive=readonly enables
cross-module inlining and interprocedural data
flow analysis of object files in an archive library
specified at link time. However, it does not enable cross-module
optimization of the archive library's code except for code
that has been inserted into other modules by cross
module inlining.

To apply cross-module optimization to code within
an archive library, -xipo_archive=writeback is
required. Note that doing so modifies the contents of the
archive library from which the code was extracted.

writeback

The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a)
before producing an executable. Any object filed contained
in the library that were optimized during the compilation
are replaced with their optimized version.

For parallel links that use a common set of archive
libraries, each link should create its own copy of archive
libraries to be optimized before linking.

If you do not specify a setting for -xipo_archive,
the compiler assumes -xipo_archive=none.

3.4.139 –xjobs=n

Compile with multiple processors.

Specify the -xjobs option to set how many processes
the compiler creates to complete its work. This option can reduce the build
time on a multi-cpu machine. In this release of the f95 compiler, -xjobs works only with the -xipo option.
When you specify -xjobs=n,
the interprocedural optimizer uses n as the maximum
number of code generator instances it can invoke to compile different files.

Generally, a safe value for n is 1.5 multiplied
by the number of available virtual processors. Using a value that is many
times the number of available virtual processors can degrade performance because
of context switching overheads among spawned jobs. Also, using a very high
number can exhaust the limits of system resources such as swap space.

You must always specify -xjobs with a value.
Otherwise an error diagnostic is issued and compilation aborts.

Multiple instances of -xjobs on the command line
override each other until the rightmost instance is reached.

The following example compiles more quickly on a system with two processors
than the same command without the -xjobs option.

example% f95 -xipo -xO4 -xjobs=3 t1.f t2.f t3.f

3.4.140 –xknown_lib=library_list

Recognize calls to a known library.

When specified, the compiler treats references to certain known libraries
as intrinsics, ignoring any user-supplied versions. This enables the compiler
to perform optimizations over calls to library routines based on its special
knowledge of that library.

The library_list is a comma-delimited list
of keywords currently to blas, blas1, blas2, blas3, and intrinsics.
The compiler recognizes calls to the following BLAS1, BLAS2, and BLAS3 library
routines and is free to optimize appropriately for the Sun Performance Library
implementation. The compiler will ignore user-supplied versions of these library
routines and link to the BLAS routines in the Sun Performance Library.

-xknown_lib=

Feature

blas1

The compiler recognizes calls to the following BLAS1 library routines:

3.4.141 –xlang=f77

(SPARC) Prepare for linking with
runtime libraries compiled with earlier versions of f77.

f95-xlang=f77 implies
linking with the f77compat library, and is a shorthand
way for linking Fortran 95 object files with older Fortran 77 object files.
Compiling with this flag insures the proper runtime environment.

Use f95-xlang=f77 when
linking f95 and f77 compiled
objects together into a single executable.

Note the following when compiling with -xlang:

Do not compile with both -xnolib and -xlang.

When mixing Fortran object files with C++, link using the
C++ compiler and specify -xlang=f95 on the CC command
line.

When mixing C++ objects with Fortran object files compiled
with any of the parallelization options, the linking CC command
line must also specify -mt.

3.4.142 –xlibmil

Synonym for -libmil.

3.4.143 –xlibmopt

Use library of optimized math routines.

Use selected math routines optimized for speed. This option usually
generates faster code. It may produce slightly different results; if so, they
usually differ in the last bit. The order on the command line for this library
option is not significant.

3.4.144 –xlic_lib=sunperf

Link with the Sun Performance Library.

For example:

f95 -o pgx -fast pgx.f -xlic_lib=sunperf

As with -l, this option should appear on the
command line after all source and object file names.

This option must be used to link with the Sun Performance Library. (See
the Sun Performance Library User’s Guide.)

3.4.145 –xlicinfo

(Obsolete) Silently ignored by compiler.

3.4.146 –xlinkopt[={1|2|0}]

(SPARC) Perform link-time optimizations
on relocatable object files.

The post-optimizer performs a number of advanced performance optimizations
on the binary object code at link-time. The optional value sets the level
of optimizations performed, and must be 0, 1, or 2.

0

The post-optimizer is disabled. (This is the default.)

1

Perform optimizations based on control flow analysis, including instruction
cache coloring and branch optimizations, at link time.

Note that the level parameter is only used when the compiler is linking.
In the example above, the postoptimization level used is 2 even though the
object binaries were compiled with an implied level of 1.

The link-time post-optimizer cannot be used with the incremental linker, ild. The -xlinkopt flag will set the default
linker to be ld. Enabling the incremental linker explicitly
withthe -xildon flag will disable the -xlinkopt option if both are specified together.

For the -xlinkopt option to be useful, at least
some, but not necessarily all, of the routines in the program must be compiled
with this option. The optimizer can still perform some limited optimizations
on object binaries not compiled with -xlinkopt.

The -xlinkopt option will optimize code coming
from static libraries that appear on the compiler command line, but it will
skip and not optimize code coming from shared (dynamic) libraries that appear
on the command line. You can also use -xlinkopt when
building shared libraries (compiling with -G ).

The link-time post-optimizer is most effective when used with run-time
profile feedback. Profiling reveals the most and least used parts of the code
and directs the optimizer to focus its effort accordingly. This is particularly
important with large applications where optimal placement of code performed
at link time can reduce instruction cache misses. Typically, this would be
compiled as shown below:

Note that compiling with this option will increase link time slightly.
Object file sizes also increase, but the size of the executable remains the
same. Compiling with the -xlinkopt and -g flags
increases the size of the excutable by including debugging information.

3.4.147 –xloopinfo

Synonym for -loopinfo.

3.4.148 –xmaxopt[=n]

Enable optimization pragma and set maximum optimization level.

n has the value 1 through 5 and corresponds
to the optimization levels of -O1 through -O5.
If not specified, the compiler uses 5.

This option enables the C$PRAGMASUNOPT=n directive when it appears in
the source input. Without this option, the compiler treats these lines as
comments. See 2.3.1.5 The OPT Directive.

If this pragma appears with an optimization level greater than the maximum
level on the -xmaxopt flag, the compiler uses the level
set by -xmaxopt.

3.4.149 –xmemalign[=<a><b>]

For memory accesses where the alignment is determinable at compile time,
the compiler will generate the appropriate load/store instruction sequence
for that data alignment.

For memory accesses where the alignment cannot be determined at compile
time, the compiler must assume an alignment to generate the needed load/store
sequence.

The -xmemalign flag allows the user to specify
the maximum memory alignment of data to be assumed by the compiler for those
indeterminate situations. It also specifies the error behavior at runtime
when a misaligned memory access does take place.

The value specified consists of two parts: a numeric alignment value, <a>, and an alphabetic behavior flag, <b>.

3.4.150 –xmodel=[small | kernel | medium]

The -xmodel option enables the compiler to create
64- bit shared objects for the Solaris x64 platforms and should only be specified
for the compilation of such objects.

This option is valid only when -m64 is specified
on 64–bit enabled x86 platforms (“x64”).

small

This option generates code for the small model in which the
virutal address of code executed is known at link time and all symbols are
known to be located in the virtual addresses in the range from 0 to 231 – 224 - 1.

kernel

Generates code for the kernel model in which all symbols are
defined to be in the range from 264 - 231 to 264 - 224.

medium

Generates code for the medium model in which no assumptions
are made about the range of symbolic references to data sections. Size and
address of the text section have the same limits as the small code model.
Applications with large amounts of static data might require —xmodel=medium when compiling with —m64.

If you do not specify -xmodel, the compiler assumes -xmodel=small. Specifying -xmodel without
an argument is an error.

It is not neccessary to compile all routines with this option as long
as you an ensure that objects being accessed are within range.

3.4.155 –xopenmp[={parallel|noopt|none}]

Enables recognition of OpenMP pragmas, and the program is
parallelized accordingly.

The minimum optimization level for -xopenmp=parallel is -xO3. The compiler changes the optimization from a lower level
to -xO3 if necessary, and issues a warning.

Defines preprocessor token _OPENMP

Invokes -stackvar automatically.

noopt

Enables recognition of OpenMP pragmas, and the program is
parallelized accordingly.

The compiler does not raise the optimization level if it is
lower than -xO3. If you explicitly set the optimization
to a level lower than -xO3, as in -xO2 -xopenmp=noopt the compiler will issue an error. If you do not specify an optimization
level with -xopenmp=noopt, the OpenMP pragmas are recognized,
the program is parallelized accordingly, but no optimization is done.

Defines preprocessor token _OPENMP

Invokes -stackvar automatically.

none

Disables recognition of OpenMP pragmas and does not change
the optimization level. (This is the compiler’s default.)

-xopenmp specified without a suboption keyword
is equivalent to -xopenmp=parallel. Note
that this default might change in later releases.

To debug OpenMP programs with dbx, compile with -g-xopenmp=noopt to be able to breakpoint within parallel regions
and display the contents of variables.

The OpenMP directives are summarized in the OpenMP API User’s
Guide.

To run a parallelized program in a multithreaded environment, you must
set the PARALLEL (or OMP_NUM_THREADS)
environment variable prior to execution. This tells the runtime system the
maximum number of threads the program can create. The default is 1. In general,
set the PARALLEL or OMP_NUM_THREADS variable
to the number of available virtual processors on the target platform.

To enable nested parallelism, you must set the OMP_NESTED environment
variable to TRUE. Nested parallelism is disabled by
default. See the Sun Studio OpenMP API User’s Guide for
details on nested parallelism.

OpenMP requires the definition of the preprocessor symbol _OPENMP to have the decimal value YYYYMM where YYYY and MM are the year
and month designations of the version of the OpenMP Fortran API that the implementation
supports. For the current Sun Studio release the value is 200525 for OpenMP
version 2.5.

When compiling and linking in separate steps, also specify -xopenmp on the link step. This is especially important when compiling
libraries that contain OpenMP directives.

3.4.156 –xpad

Synonym for -pad.

3.4.157 –xpagesize=size

Set the preferred page size for the stack and the heap.

On SPARC platforms, the size value must be
one of the following:

8K 64K 512K 4M 32M 256M 2G 16G or default

On x86 platforms, the size value must be
one of the following:

4K 2M 4M or default

For example: -xpagesize=4M

Not all these page sizes are supported on all platforms and depend on
the architecture and Solaris environment. The page size specified must be
a valid page size for the Solaris operating environment on the target platform,
as returned by getpagesizes(3C). If it is not, the
request will be silently ignored at run-time. The Solaris environment offers
no guarantee that the page size request will be honored.

You can use pmap(1) or meminfo(2)
to determine if your running program received the requested page size.

If you specify -xpagesize=default, the flag is
ignored; -xpagesize specified without a size value
is equivalent to -xpagesize=default.

This option is a macro for the combination -xpagesize_heap=size-xpagesize_stack=size.
These two options accept the same arguments as -xpagesize: 8K,64K,512K,4M,32M, 256M,2G,16G,default. You can set them both with
the same value by specifying -xpagesize=size or
you can specify them individually with different values.

Compiling with this flag has the same effect as setting the LD_PRELOAD environment variable to mpss.so.1 with
the equivalent options, or running the Solaris 9 command ppgsz(1)
with the equivalent options, before starting the program. See the Solaris
9 man pages for details.

3.4.158 –xpagesize_heap=size

Set the preferred page size for the heap.

The size value is the same as described for -xpagesize.

See -xpagesize for details.

3.4.159 –xpagesize_stack=size

(SPARC) Set the preferred page size
for the stack.

The size value is the same as described for -xpagesize.

See -xpagesize for details.

3.4.160 –xparallel

Synonym for -parallel.

3.4.161 –xpg

Synonym for -pg.

3.4.162 –xpp={fpp|cpp}

Select source file preprocessor.

The default is -xpp=fpp.

The compilers use fpp(1) to preprocess .F, .F95, or .F03 source
files. This preprocessor is appropriate for Fortran. Previous versions used
the standard C preprocessor cpp. To select cpp,
specify -xpp=cpp.

3.4.163 –xprefetch[=a[,a]]

Enable prefetch instructions on those architectures that support prefetch.

(SPARC) Adjust the compiler’s
assumed prefetch-to-load and prefetch-to-store latencies by the specified
factor. The factor must be a positive floating-point or integer number.

If you are running computationally intensive codes on large SPARC multiprocessors,
you might find it advantageous to use -xprefetch=latx:factor. This option instructs
the code generator to adjust the default latency time between a prefetch and
its associated load or store by the specified factor.

The prefetch latency is the hardware delay between the execution of
a prefetch instruction and the time the data being prefetched is available
in the cache. The compiler assumes a prefetch latency value when determining
how far apart to place a prefetch instruction and the load or store instruction
that uses the prefetched data.

Note –

The assumed latency between a prefetch and a load may not be the
same as the assumed latency between a prefetch and a store.

The compiler tunes the prefetch mechanism for optimal performance across
a wide range of machines and applications. This tuning may not always be optimal.
For memory-intensive applications, especially applications intended to run
on large multiprocessors, you may be able to obtain better performance by
increasing the prefetch latency values. To increase the values, use a factor
that is greater than 1. A value between .5 and 2.0 will most likely provide
the maximum performance.

For applications with datasets that reside entirely within the external
cache, you may be able to obtain better performance by decreasing the prefetch
latency values. To decrease the values, use a factor that is less than 1.

To use the -xprefetch=latx:factor option,
start with a factor value near 1.0 and run performance tests against the application.
Then increase or decrease the factor, as appropriate, and run the performance
tests again. Continue adjusting the factor and running the performance tests
until you achieve optimum performance. When you increase or decrease the factor
in small steps, you will see no performance difference for a few steps, then
a sudden difference, then it will level off again.

yes

-xprefetch=yes is the same as -xprefetch=auto,explicit

no

-xprefetch=no is the same as -xprefetch=no%auto,no%explicit

With -xprefetch, -xprefetch=auto,
and -xprefetch=yes, the compiler is free to insert
prefetch instructions into the code it generates. This may result in a performance
improvement on architectures that support prefetch.

3.4.163.1 Defaults:

If -xprefetch is not specified, -xprefetch=no%auto,explicit is assumed.

If only -xprefetch is specified, -xprefetch=auto,explicit is assumed.

The default of no%auto is assumed unless explicitly
overridden with the use of -xprefetch without any arguments
or with an argument of auto or yes.
For example, -xprefetch=explicit is the same as -xprefetch=explicit,no%auto.

The default of explicit is assumed unless explicitly
overridden with an argument of no%explicit or an argument
of no. For example, -xprefetch=auto is
the same as -xprefetch=auto,explicit.

If automatic prefetching is enabled, such as with -xprefetch or -xprefetch=yes, but a latency factor is not specified, then -xprefetch=latx:1.0 is assumed.

3.4.163.2 Interactions:

With -xprefetch=explicit, the compiler will recognize
the directives:

$PRAGMA SUN_PREFETCH_READ_ONCE (name)

$PRAGMA SUN_PREFETCH_READ_MANY (name)

$PRAGMA SUN_PREFETCH_WRITE_ONCE (name)

$PRAGMA SUN_PREFETCH_WRITE_MANY (name)

The -xchip setting effects the determination
of the assumed latencies and therefore the result of a latx:factor setting.

The latx:factor suboption
is valid only when automatic prefetching (auto) is
enabled on SPARC processors.

3.4.163.3 Warnings:

Explicit prefetching should only be used under special circumstances
that are supported by measurements.

Because the compiler tunes the prefetch mechanism for optimal performance
across a wide range of machines and applications, you should only use -xprefetch=latx:factor when the performance tests indicate
there is a clear benefit. The assumed prefetch latencies may change from release
to release. Therefore, retesting the effect of the latency factor on performance
whenever switching to a different release is highly recommended.

3.4.164 –xprefetch_auto_type=indirect_array_access

Generate indirect prefetches for a data arrays accessed indirectly.

Generates indirect prefetches for the loops indicated by the option -xprefetch_level={1|2|3} in the same fashion the prefetches for direct memory accesses
are generated. The prefix no% can be added to negate
the declaration.

The default is -xprefetch_auto_type=no%indirect_array_access.

Requires -xprefetch=auto and an optimization
level -xO3 or higher.

Options such as -xdepend can affect the aggressiveness
of computing the indirect prefetch candidates and therefore the aggressiveness
of the automatic indirect prefetch insertion due to better memory alias disambiguation
information.

3.4.165 -xprefetch_level={1|2|3}

Control the automatic generation of prefetch instructions.

This option is only effective when compiling with:

-xprefetch=auto,

with optimization level 3 or greater,

on a platform that supports prefetch .

The default for -xprefetch=auto without specifying -xprefetch_level is level 2.

3.4.166 –xprofile={collect[:name]|use[:name]|tcov}

Compiling with high optimization levels (-xO5)
is enhanced by providing the compiler with runtime performance feedback. To
produce the profile feedback the compiler needs to do its best optimizations,
you must compile first with -xprofile=collect, run
the executable against a typical data set, and then recompile at the highest
optimization level and with -xprofile=use.

collect[:name]

Collect and save execution frequency data for later use by
the optimizer with -xprofile=use. The compiler generates
code to measure statement execution frequency.

The name is the name of the program that
is being analyzed. This name is optional. If name is
not specified, a.out is assumed to be the name of the
executable.

At runtime a program compiled with -xprofile=collect:name will create by default the subdirectory name.profile to hold the runtime feedback information. The program
writes its runtime profile data to the file named feedback in
this subdirectory. If you run the program several times, the execution frequency
data accumulates in the feedback file; that is, output
from prior runs is not lost.

You can set the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR to control the file and directory where a program
compiled with -xprofile=collect writes its runtime
profile data. With these variables set, the program compiled with -xprofile=collect writes its profile data to $SUN_PROFDATA_DIR/$SUN_PROFDATA.

These environment variables similarly control the path and names of
the profile data files written by tcov, as described
in the tcov(1) man page.

Profile collection is “MT-safe”. That is, profiling a program
that does its own multitasking by compiling with -mt and
calling the multitasking library directly will give accurate results.

When compiling and linking in separate steps, the link step must also
specify -xprofile=collect if it appears on the compile
step.

As with collect:nm, the nm is
optional and may be used to specify the name of the program.

The program is optimized by using the execution frequency data previously
generated and saved in the profile data files written by a previous execution
of the program compiled with -xprofile=collect.

The source files and other compiler options must be exactly the same
as used for the compilation that created the compiled program that generated
the feedback file. If compiled with -xprofile=collect:nm, the same program name nm must
appear in the optimizing compilation: -xprofile=use:nm.

See also -xprofile_ircache for speeding up compilationg
between the collect and use phases.

See also -xprofile_pathmap for controlling where
the compiler looks for profile data files.

Code instrumentation is similar to that of -a,
but .d files are no longer generated for each source
file. Instead, a single file is generated, whose name is based on the name
of the final executable. For example, if stuff is the
executable file, then stuff.profile/tcovd is the data
file.

When running tcov, you must pass it the -x option to make it use the new style of data. If not, tcov uses the old .d files, if any, by default
for data, and produces unexpected output.

Unlike -a, the TCOVDIR environment
variable has no effect at compile–time. However, its value is used at
program runtime to identify where to create the profile subdirectory.

See the tcov(1) man page, the “Performance
Profiling” chapter of the Fortran Programming Guide,
and the Program Performance Analysis Tools manual for
more details.

Note –

The report produced by tcov can be unreliable
if there is inlining of subprograms due to -O4 or
-inline. Coverage of calls to routines that have been
inlined is not recorded.

3.4.167 –xprofile_ircache[=path]

(SPARC) Save and reuse compilation
data between collect and use profile phases.

Use with -xprofile=collect|use to
improve compilation time during the use phase by reusing compilation data
saved from the collect phase.

If specified, path will override the location
where the cached files are saved. By default, these files will be saved in
the same directory as the object file. Specifying a path is useful when the
collect and use phases happen in two different places.

With large programs, compilation time in the use phase can improve significantly
by saving the intermediate data in this manner. But this will be at the expense
of disk space, which could increase considerably.

3.4.168 –xprofile_pathmap=collect_prefix:use_prefix

(SPARC) Set path mapping for profile
data files.

Use the -xprofile_pathmap option with the -xprofile=use option.

Use -xprofile_pathmap when the compiler is unable
to find profile data for an object file that is compiled with -xprofile=use, and:

You are compiling with -xprofile=use into
a directory that is not the directory used when previously compiling with -xprofile=collect.

Your object files share a common basename in the profile but
are distinguished from each other by their location in different directories.

The collect-prefix is the prefix of the UNIX
pathname of a directory tree in which object files were compiled using -xprofile=collect.

The use-prefix is the prefix of the UNIX
pathname of a directory tree in which object files are to be compiled using -xprofile=use.

If you specify multiple instances of -xprofile_pathmap,
the compiler processes them in the order of their occurrence. Each use-prefix specified by an instance of -xprofile_pathmap is
compared with the object file pathname until either a matching use-prefix is identified or the last specified use-prefix is
found not to match the object file pathname.

3.4.169 –xrecursive

Normally, only subprograms defined with the RECURSIVE attribute
can call themselves recursively.

Compiling with -xrecursive enables subprograms
to call themselves, even if they are not defined with the RECURSIVE attribute.
But, unlike subroutines defined RECURSIVE, use of this
flag does not cause local variables to be allocated on the stack by default.
For local variables to have separate values in each recursive invocation of
the subprogram, compile also with -stackvar to put
local variables on the stack.

3.4.170 –xreduction

3.4.171 –xregs=r

r is a comma–separated list that consists
of one or more of the following:

[no%]appl, [no%]float.

Where the % is shown, it is a required character.

Example: -xregs=appl,no%float

Prefix the suboption with no% to disable the
feature.

appl

(SPARC) Allow the compiler to generate code using the application
registers as scratch registers. These are the g2, g3,
and g4 registers on 32–bit processors, and g2, g3 on 64–bit processors.

float

(SPARC only) Allow the compiler to use the floating–point
registers as scratch registers for integer values. This option has no effect
on the compiler’s use of floating-point registers for floating-point
values.

no%float

Do not use the floating–point registers. With this option,
a source program cannot contain any floating–point code.

frameptr

(x86 only) Allow the compiler to use the frame-pointer register
(%ebp on 32–bit x86, %rbp on
64–bit x86 processors) as an unallocated callee-saves register to improve
program performance. -xregs=frameptr is ignored when
also compiling with -xpg or -p.

The default is -xregs=appl,float on SPARC platforms,-xregs=appl,float,no%frameptr on x86.

It is strongly recommended that you compile code intended for shared
libraries that will link with applications with -xregs=no%appl,float.
At the very least, the shared library should explicitly document how it uses
the application registers so that applications linking with those libraries
know how to cope with the issue.

For example, an application using the registers in some global sense
(such as using a register to point to some critical data structure) would
need to know exactly how a library with code compiled without -xregs=no%appl is using the application registers in order to safely link with
that library.

3.4.172 –xs

Allow debugging by dbx without object (.o) files.

With -xs, all debug information is copied into
the executable file. If you move executables to another directory, then you
can use dbx and ignore the object (.o)
files. Use this option when you cannot retain the .o files.

Without -xs, if you move the executables, you
must move both the source files and the object (.o)
files, or set the path with either the dbx pathmap or use command.

3.4.173 –xsafe=mem

(SPARC) Allow the compiler to assume
that no memory protection violations occur.

Using this option allows the compiler to assume no memory–based
traps occur. It grants permission to use the speculative load instruction
on the SPARC V9 platforms.

This option is effective only when used with optimization level -O5.

Caution –

Because non-faulting loads do not cause a trap when a fault
such as address misalignment or segmentation violation occurs, you should
use this option only for programs in which such faults cannot occur. Because
few programs incur memory-based traps, you can safely use this option for
most programs. Do not use this option with programs that explicitly depend
on memory-based traps to handle exceptional conditions.

3.4.174 –xsb

(Obsolete) Synonym for -sb.

3.4.175 –xsbfast

(Obsolete) Synonym for -sbfast.

3.4.176 –xspace

Do no optimizations that increase the
code size.

Example: Do not unroll or parallelize loops if it increases code size.

3.4.177 –xtarget=t

Specify the target platform for the instruction set and optimization.

t must be one of: native, native64, generic, generic64, platform–name.

The -xtarget option permits a quick and easy
specification of the -xarch, -xchip,
and -xcache combinations that occur on real platforms.
The only meaning of -xtarget is in its expansion.

The performance of some programs may benefit by providing the compiler
with an accurate description of the target computer hardware. When program
performance is critical, the proper specification of the target hardware could
be very important. This is especially true when running on the newer SPARC
processors. However, for most programs and older SPARC processors, the performance
gain is negligible and a generic specification is sufficient.

The actual expansion of -xtarget values can change
from release to release. You can always determine the expansion that the compiler
will use with the -dryrun flag:

3.4.177.3 x86 Platforms

Compiling for 64-bit Solaris OS on 64-bit enabled x86 platform is indicated
by the -m64 flag. For example, compiling with -xtarget=opteron is not necessary or sufficient. If -xtarget is specified, the -m64 option must appear
after the -xtarget flag, as in:

-xtarget=opteron -m64

otherwise the compilation will be 32-bit x86.

3.4.178 –xtime

Synonym for -time.

3.4.179 –xtypemap=spec

Specify default data mappings.

This option provides a flexible way to
specify the byte sizes for default data types. This option applies to both
default-size variables and constants.

The specification string spec may contain
any or all of the following in a comma-delimited list:

real:sizedouble:sizeinteger:size

The allowable combinations on each platform are:

real:32

real:64

double:64

double:128

integer:16

integer:32

integer:64

For example:

–xtypemap=real:64,double:64,integer:64

maps both default REAL and DOUBLE to
8 bytes.

This option applies to all variables declared with default specifications
(without explicit byte sizes), as in REALXYZ (resulting
in a 64-bit XYZ). Also, all single-precision REAL constants are promoted to REAL*8.

Note that INTEGER and LOGICAL are
treated the same, and COMPLEX is mapped as two REALs. Also, DOUBLECOMPLEX will
be treated the way DOUBLE is mapped.

3.4.180 –xunroll=n

Synonym for -unroll=n.

3.4.181 –xvector[= [[no%]lib, [no%]simd, %none] ]

Enable automatic generation of calls to the vector library functions.

This option requires compiling with default rounding mode -fround=nearest when compiling with -xvector.

-xvector=lib enables the compiler to transform
math library calls within loops into single calls to the equivalent vector
math routines when such transformations are possible. This could result in
a performance improvement for loops with large loop counts. -xvector=no%lib disables this feature.

-xvector=simd enables the compiler to use the
native x86 SSE SIMD instructions to improve performance of certain loops.
The compiler can only accept this switch if the target architecture supports
SIMD instructions. For example, you must specify -xarch=sse2 -m64 or -xarch=generic64. You must also specify an optimization level of -xO3 or
above as well as -xdepend with -xvector=simd. -xvector=no%simd disables this feature.

You will get better performance if you specify both -xvector=simd and -fsimple=2 than with -xvector=simd alone. However, your floating point results can be slightly different
because -fsimple=2 allows reordering of floating-point
operations.

The default is -xvector=%none. If you specify -xvector, but do not provide a sub-option, the compiler assumes -xvector=lib.

The compiler includes the libmvec libraries in the load step. If you
specify -xvector=lib at compile time, you must also
specify it at link time.

3.4.182 –ztext

The general purpose
of -ztext is to verify that a generated library is
pure text; instructions are all position–independent code. Therefore,
it is generally used with both -G and -pic.

With -ztext, if ld finds
an incomplete relocation in the text segment, then
it does not build the library. If it finds one in the data segment,
then it generally builds the library anyway; the data segment is writable.

Without -ztext, ld builds
the library, relocations or not.

A typical use is to make a library from both source files and object
files, where you do not know if the object files were made with -pic.

Example: Make library from both source and object files:

demo% f95 -G -pic -ztext -o MyLib -hMyLib a.f b.f x.o y.o

An alternate use is to ask if the code is position–independent
already: compile without -pic, but ask if it is pure
text.

Example: Ask if it is pure text already—even without -pic:

demo% f95 -G -ztext -o MyLib -hMyLib a.f b.f x.o y.o

If you compile with -ztext and ld does
not build the library, then you can recompile without -ztext,
and ld will build the library. The failure to build
with -ztext means that one or more components of the
library cannot be shared; however, maybe some of the other components can
be shared. This raises questions of performance that are best left to you,
the programmer.