NAME
f95, f90 - Fortran 95 compiler
SYNOPSIS
May be invoked by either f95 or f90 commands; they are
equivalent.
f95 [ -aligncommon[=a] ] [ -ansi ] [ -arg=local ]
[ -autopar ] [ -Bx ] [ -C ] [ -c ]
[ -copyargs ] [ -Dnm[=def] ] [ -dalign ]
[ -dbl_align_all[={yes|no}] ] [ -depend[={yes|no}] ]
[ -dryrun ] [ -d{y|n} ] [ -e ] [ -erroff[=taglist] ]
[ -errtags[={yes|no}] ] [ -errwarn[=taglist] ]
[ -ext_names=e ] [ -F ] [ -f ]
[ -f77[=list] ] [ -fast ] [ -fixed ] [ -flags ]
[ -fma={none|fused} ] [ -fnonstd ] [ -fns[={yes|no}] ]
[ -fpover[={yes|no}] ] [ -fpp ] [ -fprecision=p ]
[ -free ] [ -fround=r ] [ -fsimple[=n] ] [ -fstore ]
[ -ftrap=t ] [ -G ] [ -g ]
[ -hnm ] [ -help ] [ -Ipath ] [ -inline=rl ]
[ -iorounding[=r] ] [ -keeptmp ] [ -KPIC ] [ -Kpic ]
[ -Lpath ] [ -lx ] [ -libmil ] [ -library=sunperf ]
[ -loopinfo ] [ -Mpath ]
[ -m32|-m64 ] [ -moddir=path ] [ -mt ]
[ -native ] [ -noautopar ] [ -nodepend ]
[ -nofstore ] [ -nolib ]
[ -nolibmil ] [ -noreduction ] [ -norunpath ]
[ -O[n] ] [ -o nm ] [ -onetrip ]
[ -openmp[=a] ] [ -PIC ] [ -p ]
[ -pad[=a] ] [ -pg ] [ -pic ]
[ -Qoption pr ls ] [ -qp ] [ -R list ] [ -r8const ]
[ -recl=a[,b] ] [ -reduction ] [ -S ] [ -s ]
[ -silent ] [ -stackvar ] [ -stop_status={yes|no} ]
[ -temp=path ] [ -time ] [ -traceback[=list] ]
[ -U ] [ -Uname ] [ -u ]
[ -unroll=n ] [ -use=list ] [ -V ] [ -v ] [ -vax=v ]
[ -vpara ] [ -Wc,arg ] [ -w[n] ]
[ -Xlinker arg ] [ -Xlist[z] ]
[ -xaddr32[={no|yes}] ] [ -xalias[=a[,a]...] ]
[ -xannotate[={yes|no}] ] [ -xarch=a ]
[ -xassume_control[=a[,a]...] ]
[ -xautopar ] [ -xbinopt={prepare|off} ]
[ -xcache=c ]
[ -xcheck=v ] [ -xchip=c ] [ -xcode=v ]
[ -xcommonchk[={no|yes}] ]
[ -xdebugformat={stabs|dwarf} ] [ -xdepend ]
[ -xdryrun ] [ -xF ]
[ -xfilebyteorder=options ]
[ -xhasc[={yes|no}] ] [ -xhelp=h ]
[ -xhwcprof[=e] ] [ -xia[=i] ]
[ -xinline=rl ] [ -xinstrument=d ] [ -xinterval=i ]
[ -xipo[=n] ] [ -xipo_archive=a ]
[ -xivdep[=p] ] [ -xjobs=n ] [ -xkeepframe[=p] ]
[ -xknown_lib=lib ] [ -xl ] [ -xld ] [ -xlang=f77 ]
[ -xlibmil ] [ -xlibmopt ] [ -xlicinfo ]
[ -xlinkopt[=level] ]
[ -xloopinfo ] [ -xmaxopt[=n] ]
[ -xmemalign[=ab] ] [ -xmodel=[a] ] [ -xnolib ]
[ -xnolibmil ] [ -xnolibmopt ] [ -xO[n] ]
[ -xopenmp[=a] ] [ -xpad[=a] ] [ -xpagesize=n ]
[ -xpagesize_heap=n ] [ -xpagesize_stack=n ]
[ -xpec[={yes|no}] ] [ -xpg ] [ -xpp=p ]
[ -xprefetch=a[,a]]
[ -xprefetch_auto_type=[no%]indirect_array_access ]
[ -xprefetch_level=n ]
[ -xprofile=p ] [ -xprofile_ircache=path ]
[ -xrecursive ] [ -xreduction ] [ -xregs=r ] [ -xs ]
[ -xsafe=mem ]
[ -xspace ] [ -xtarget=t ] [ -xtime ]
[ -xtypemap=spec ] [ -xunroll=n ]
[ -xvector[={v}] ] [ -xvpara ] [ -ztext ]
source file(s) ... [ -lx ]
DESCRIPTION
Oracle Solaris Studio 12.3 Fortran 95 compiler, version 8.6
The f95 compiler accepts standard-compliant Fortran 95
source code programs. It also accepts some Fortran 2003
features, extensions for interval arithmetic, and the
OpenMP[tm] Fortran 95 API version 3.1. It also accepts many
FORTRAN 77 (f77) language extensions under the -f77
compatibility option, and VAX VMS Fortran extensions (-vax).
Version 8.6 of the Fortran 95 compiler f95 is released as a
component of Oracle Solaris Studio 12.3, and is available
for the Oracle Solaris Operating System (Oracle Solaris OS)
on SPARC and x86 platforms, and on Linux x86 platforms.
See the Oracle Solaris Studio 12.3 Release Notes for a
complete list of system environments and versions.
Complete documentation for this release is available on the
Oracle Technical Network (OTN) Solaris Studio website:
http://oracle.com/technetwork/server-storage/solarisstudio
The OTN website is a complete resource for Oracle Solaris
Studio and includes many technical articles detailing best
practices and deep dives into various programming
technologies and other topics.
For the full description of all new features and
functionality in the Oracle Solaris Studio suite, see the
What's New in this Release guide.
A man page, by definition, is a quick reference. For more
detailed information on using the f95 compiler and its
options, see the Fortran User Guide and the Fortran
Programming Guide.
See the Fortran User's Guide for complete details on how to
use the f95 compiler. The user guide details all the
options, pragma directives, and environment variables
accepted by f95, and describes any differences between
standard Fortran 95 and this Fortran 95 compiler.
See the Fortran Programming Guide for information on program
performance and optimization, parallelization, and porting
from other Fortran platforms.
A list of relevant Oracle Solaris Studio documentation
appears at the end of this man page.
COMPILING FOR 64-BIT PLATFORMS:
Use the -m32 and -m64 options to specify the memory model of
the target compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit memory model
definition, and should be used only to specify the
instruction set of the target processor.
The ILP32 model specifies that C-language int, long, and
pointer data types are all 32-bits wide. The LP64 model
specifies that long and pointer data types are all 64-bits
wide. The Oracle Solaris and Linux OS also support large
files and large arrays under the LP64 memory model.
When compiling with -m64, the resulting executable will work
only on 64-bit SPARC or x86 processors under Oracle Solaris
OS or Linux OS running a 64-bit kernel. Compilation,
linking, and execution of 64-bit objects can only take place
in a Oracle Solaris or Linux OS that supports 64-bit
execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when
compiling for x86 Oracle Solaris platforms.
Programs compiled with -xarch set to sse, sse2, sse2a, or
sse3 and beyond must be run only on platforms that provide
these extensions and features.
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.
Numerical results on x86 might differ from results on SPARC
due to the x86 80-bit floating-point registers. To minimize
these differences, use the -fstore option or compile with
-xarch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Oracle Solaris and
Linux because the intrinsic math libraries (for example,
sin(x)) are not the same.
Binary Compatibility Verification
Program binaries compiled and built using specialized -xarch
hardware flags are verified that they are being run on the
appropriate platform. Running programs compiled with
specialized -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.
This warning extends also to programs that employ .il inline
assembly language functions or __asm() assembler code that
utilize SSE, SSE2, SSE2a, and SSE3 (and beyond) instructions
and extensions.
User-Supplied Default Compiler Options Startup File
The default compiler options file enables the user to
specify a set of default options that are applied to all
compiles, unless otherwise overridden. For example, the file
could specify that all compiles default at -xO2, or
automatically include the file setup.il.
At startup, the compiler searches for a default options file
listing default options it should include for all compiles.
The environment variable SPRO_DEFAULTS_PATH specifies a
colon-separated list of directories to search for the the
defaults file.
If the environment variable is not set, a standard set of
defaults is used. If the environment variable is set but is
empty, no defaults are used.
The defaults file name must be of the form
compiler.defaults, where compiler is one of the following:
cc, c89, c99, CC, ftn, or lint. For example, the defaults
for the Fortran compiler would be ftn.defaults
If a defaults file for the compiler is found in the
directories listed in SPRO_DEFAULTS_PATH, the compiler will
read the file and process the options prior to processing
the options on the command line. The first defaults file
found will be used and the search terminated.
System administrators may create system-wide default files
in Studio-install-path/prod/etc/config. If the environment
variable is set, the installed defaults file will not be
read.
The format of a defaults file is similar to the command
line. Each line of the file may contain one or more
compiler options separated by white space. Shell expansions,
such as wild cards and substitutions, will not be applied to
the options in the defaults file.
The value of the SPRO_DEFAULTS_PATH and the fully expanded
command line will be displayed in the verbose output
produced by options -#, -###, and -dryrun.
Options specified by the user on the command line will
usually override options read from the defaults file. For
example, if the defaults file specifies compiling with -xO4
and the user specifies -xO2 on the command line, -xO2 will
be used.
Some options appearing in the default options file will be
appended after the options specified on the command line.
These are the preprocessor option -I, linker options -B, -L,
-R, and -l, and all file arguments, such as source files,
object files, archives, and shared objects.
The following is an example of how a user-supplied default
compiler option startup file might be used.
demo% cat /project/defaults/ftn.defaults
-fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
demo% setenv SPRO_DEFAULTS_PATH /project/defaults
demo% f95 -c -I/local/hdrs -L/local/libs -lliblocal tst.f
The compiler command is now equivalent to:
f95 -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.f -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way
to set the defaults for an entire project, it can become the
cause of hard to diagnose problems. Set the environment
variable SPRO_DEFAULTS_PATH to an absolute path rather than
the current directory to avoid such problems.
The interface stability of the default options file is
uncommitted. The order of option processing is subject to
change in a future release.
OPTIONS
Options valid only on SPARC platforms are marked (SPARC).
Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be
used going forward. They are provided only for compatibility
with earlier releases. Use the indicated replacement option.
See ld(1) for linker options.
f95 compiles "silently". Except for error and warning
messages, it does not issue "progress" messages during
compilation.
In general, processing of the compiler options is from left
to right, permitting selective overriding of macro options.
This rule does not apply to linker or preprocessor options.
In the syntax of the command-line options, items shown in
square brackets ( [] ) are optional. Curly brackets enclose
a bar-separated list of literal items to be chosen, as in
{yes | no | maybe } . The first item in a list usually
indicates the default value when the flag appears without a
value.
For example, -someoption[={no|yes}] implies -someoption is
the same as -someoption=no .
LIST OF OPTIONS
-aligncommon[={1|2|4|8|16}]
Specify alignment of data in common blocks and standard
numeric sequence types.
The value specified indicates the maximum alignment (in
bytes) for data elements within common blocks and
standard numeric sequence types. For example,
-aligncommon=4 would align common block 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.
The default, when -aligncommon is not specified, aligns
common block and standard numeric sequence data on at
most 4-byte boundaries.
Specifying -aligncommon without a value defaults to 1
on all platforms: All data aligns on byte boundaries
(no padding between elements).
-aligncommon=16 reverts to -aligncommon=8 when
compiling for platforms that are not 64-bit enabled.
Using -aligncommon=1 on SPARC platforms might result in
a bus error due to misalignment, requiring an
appropriate choice of the -xmemalign option be used.
Depending on the application, -xmemalign=1s, -
xmemalign=4ior -xmemalign=8i should give optimal
performance while avoiding the segmentation fault.
See also -xmemalign
-ansi
Identify nonstandard extensions.
-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 nonstandard.
-autopar
Enable automatic loop parallelization
Find and parallelize appropriate loops. Do dependence
analysis (analyze loops for data dependences). Do loop
restructuring. If optimization is not -O3 or higher,
it is raised to -O3.
Also specify the -stackvar option when using any of the
parallelization options. 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 you do your own thread management.
See note under -mt.
Also, -autopar is inappropriate on a single-processor
system, and will degrade performance.
For more information, see the Parallelization chapter
in the Fortran Progamming Guide.
Number of Threads: Use the OMP_NUM_THREADS environment
variable to specify the number of threads to use when
running a program automatically parallelized by the
-xautopar compiler option. If OMP_NUM_THREADS is not
set, the default number of threads used is 2. To use
more threads, set OMP_NUM_THREADS to a higher value.
Set OMP_NUM_THREADS to 1 to run with just one thread.
In general, set OMP_NUM_THREADS to the available number
of virtual processors on the running system, which can
be determined by using the Oracle Solaris psrinfo(1)
command. See the OpenMP API User's Guide for more
information.
If you use -autopar and compile and link in one step,
linking will automatically include the microtasking
library and the threads-safe Fortran runtime library.
If you use -autopar and compile and link in separate
steps, then you must link with f95 -autopar as well.
-B{dynamic|static}
Prefer dynamic or require static library linking.
Indicates that either dynamic library linking is
preferred, or static linking required for any libraries
listed later in the command. This is a linker option.
The default is -Bdynamic.
-Bdynamic: Prefer dynamic linking (shared libraries)
-Bstatic : Require static linking (no shared
libraries)
If you specify static but the linker finds only a
dynamic library, then the library is not linked and a
warning issued.
However, if you specify dynamic but the linker finds
only a static version, that library is linked with no
warning.
You can toggle between -Bdynamic and -Bstatic on the
command line, linking some libraries statically and
others dynamically.
Because these are linker options, compiling with -
Bstatic or -Bdynamic requires the same options on a
linker command if done in separate steps.
In a 64-bit 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). As a result, -Bstatic and -dn can cause
linking errors in 64-bit Oracle Solaris OS.
Applications must link with the dynamic libraries in
these cases.
Note: 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.
-C Check array references for out of range subscripts and
conformance.
Arrays subscripted beyond their declared sizes can
result in unexpected results, including segmentation
faults. The -C option checks for possible array
subscript violations in the source code and during
execution.
With the -C option specified, run-time array subscript
violations are treated as an error. The compiler will
also flag array subscript range violations in the
source code as warnings.
Compiling with -C also adds checks for array
conformance at runtime in statements using array
syntax.
This option will increase the size of the executable
file and degrade execution performance. It should only
be used while debugging.
-c Compile and produce a .o file for each source file
without linking. You can explicitly name a single
object file by using the -o option. When the compiler
produces object code for each or input file, it always
creates an object file in the current working
directory. If you suppress the linking step, you also
suppress the removal of the object files.
-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 for
changing a constant.
Without -copyargs, if you pass a constant argument to a
subroutine, and then within the subroutine try to
change that constant, the run gets a runtime error.
With -copyargs, if you pass a constant argument to a
subroutine, and then within the subroutine change that
constant, the run does not necessarily get a runtime
error.
Programs that require compilation with the -copyargs
flag are not Fortran standard-compliant.
-Dname[=def]
Define symbol name for the source code preprocessor.
This is equivalent to a #define directive in the
source. If no def is given, name is defined as 1. This
option applies to .F .F90 .F95 .F03 suffix files only.
The following symbols are predefined on appropriate
systems; note the two leading underscores:
__sparc, __sparcv8, __sparcv9, __unix, __sun,
__i386, __x86_64, __amd64, __SVR4, __SunOS_5_10
__SunOS_5_11
Fortran syntax might not support the actual values of
these symbols--they should appear only on fpp or cpp
preprocessor statements, such as conditionals:
#ifdef __sparc
Corresponding older values (prior releases) are:
sparc, unix, sun,
These earlier predefined values might be deleted in a
future release.
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 understand 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.
-dalign
Align COMMON blocks and standard numeric sequence types
and generate faster multi-word load/stores.
This flag changes the data layout in COMMON blocks (and
EQUIVALENCE classes), and enables the compiler to
generate faster multi-word load/stores for that data.
-dalign is a macro equivalent to
-xmemalign=8s -aligncommon=16 on SPARC platforms,
-aligncommon=8 on 32-bit x86 platforms, and
-aligncommon=16 on 64-bit x86 platforms.
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
16-byte boundaries for quad-precision when compiling
for 64-bit platforms with -m64.) The default alignment
in COMMON blocks is on 4-byte boundaries.
Using -dalign along with
-xtypemap=real:64,double:64,integer:64 also causes 64-
bit integer variables to be double-word aligned on
SPARC.
Using -dalign, can result in nonstandard FORTRAN
alignment which could cause problems with variables in
EQUIVALENCE or COMMON and can render the program non-
portable if -dalign is required.
If you compile one subprogram or file with -dalign,
then all subprograms and files in the program unit must
be compiled with -dalign.
Because -dalign invokes -aligncommon, the alignment of
standard numeric sequence types is also affected.
The -fast flag selects -dalign.
-dbl_align_all[={yes|no}]
Force alignment of data on 8-byte boundaries.
If yes all variables will be aligned on 8-byte
boundaries. Default is -dbl_align_all=no. By itself,
-dbl_align_all is equivalent to -dbl_align_all=yes.
When compiling for 64-bit SPARC 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.
If used, all routines must be compiled with this
option.
-depend[=yes|no]
Analyze loops for data dependence and restructuring.
-depend is equivalent to -depend=yes and enables loop
dependence analysis. It is on by default on all
platforms.
-depend=no disables DO loop data dependence analysis
-dryrun
Show commands built by the f95 driver but do not
compile.
Useful when debugging, this option displays the
commands the compiler will run to perform the
compilation.
-d{y|n}
Allow/disallow dynamic libraries for executable
Allow or disallow dynamic libraries for the entire
executable. This flag is a linker option.
The default is -dy.
-dy: Allow dynamic libraries.
-dn: Do not allow dynamic libraries.
Unlike -B{dynamic|static}, this option applies to the
whole executable and need appear only once on the
command line.
-d{y|n} are linker options. If you compile and link in
separate steps with these options, then you need the
same option in the final link step.
In a 64-bit 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). As a result, -Bstatic and -dn can cause
linking errors in 64-bit Oracle Solaris OS platforms
and 32-bit Oracle Solaris x86 platforms and all 32-bit
Oracle Solaris platforms starting with the Solaris 10
release. Applications must link with the dynamic
libraries in these cases.
-e Extend source line maximum length to 132 characters.
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
might be inserted in the constants.
-erroff[={%all|%none|taglist}]
Suppress warning messages listed by tag name.
This option only affects warning messages. Error
messages are not affected. The taglist specifies a
list of comma-separated tag names that appear with
warning messages. If just %all is specified, all
warnings are suppressed (this is equivalent to the -w
option.) If just %none is specified, no warnings are
suppressed. -erroff specified without a value is
equivalent to -erroff=%all.
(See also -errtags.)
-errtags[={yes|no}]
Display the message tag with each warning message.
The compiler's internal error tag name appears along
with error messages. The default is not to display the
tag (-errtags=no). The second default (-errtags without
a value) is -errtags=yes.
-errwarn[={%all|%none|taglist}]
Treat warning messages as errors.
The taglist specifies a list of comma-separated tag
names of warning messages that should be treated as
errors. If just %all is specified, all warnings are
treated as errors. If just %none is specified, no
warnings are treated as errors.
See also -errtags.
-ext_names=e
Create external names with or without underscores.
e must be plain or underscores or fsecond-underscore.
The default is underscores.
plain
Do not use trailing underscores.
underscores
Use trailing underscores.
fsecond-underscore
Append two underscores to external names that contain
an underscore, and a single underscore to those that do
not.
An external name is a name of a subroutine, function,
block data subprogram, or labeled common. This option
affects both the name in the routine itself and, of
course, the name used in the calling statement (both
symdefs and symrefs).
fsecond-underscore is provided for compatibility with
gfortran.
-F Invoke the source file preprocessor, but do not compile
Apply the fpp preprocessor to .F90, .F95, .F03, and .F
files and put the result in the file with the suffix
changed to .f90, .f95, .f03,or .f, but do not compile.
fpp is the default preprocessor for Fortran. The C
preprocessor, cpp, can be selected instead by
specifying -xpp=cpp.
-f Align double- and quad-precision data in COMMON blocks.
This flag changes the data layout in COMMON blocks (and
EQUIVALENCE classes): 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.
-f is is a legacy option equivalent to -aligncommon=16.
Use of -aligncommon is preferred.
This option applies to both real and complex data.
Resulting code might not be standard and might not be
portable.
If you compile one subprogram with -f, compile all
subprograms of the program with -f.
By itself, this option does not enable the compiler to
generate faster double word fetch/store instructions
and double and quad precision data. Only -dalign will
do this.
-f77[=list]
Select Fortran 77 compatibility mode.
list is a comma-separated list selected from the
following possible keywords:
%all Select all the f77 compatibility features.
%none Disable the f77 compatibility features.
output Generate f77-style formatted output, including
list-directed and namelist output.
input Accept input formats allowed by f77.
tab Enable f77-style TAB-formatting, including
unlimited source line length. Also, no blank
padding will be added to source lines shorter
than 72 characters.
backslash
Accept a backslash character as the beginning
of an escape sequence in character strings.
intrinsics
Limit recognition of intrinsics to only Fortran
77 intrinsics.
logical Accept Fortran 77 usage of logical variables,
such as:
- Allow assignment of integer values to logical
variables.
- Allow arithmetic expressions in place of
logical expressions in conditional
statements, with .NE.0 representing .TRUE..
- Allow use of relational operators .EQ. and
.NE. with logical operands.
subscript
Allow non-integer expressions as array
subscripts.
misc Allow other miscellaneous Fortran 77 extensions
not supported by Fortran 95.
All keywords can be prefixed by no% to disable the
corresponding feature, as in:
-f77=%all,no%backslash
The default, when -f77 is not specified is -f77=%none.
When -f77 is used without a list, it is equivalent to
-f77=%all.
Trapping on Exceptions
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, which was to allow execution to
continue after arithmetic exceptions. It also made the
program call ieee_retrospective on program exit to
report on any arithmetic exceptions that occurred
during execution. Specify -ftrap=%none after -f77 to
revert to trapping that mimics Fortran 77's behavior.
Migrating FORTRAN 77 Programs to Fortran
See the chapter on FORTRAN 77 compatibility in the
Fortran User's Guide for details on -f77 and the
compatibility features it provides. See also the
-xalias flag for handling nonstandard FORTRAN 77
programming that can cause incorrect results.
Compile with f77
A Fortran 77 compiler script has been provided for
convenience. The f77 command-line script invokes the
f95 compiler with the appropriate set of options for
Fortran 77 compatibility. See the f77(1) man page for
details.
-fast
Select options that optimize execution performance.
-fast provides high performance for certain
applications. However, the particular choice of
options might not be appropriate for your application.
Use -fast as a good starting point for compiling your
application for best performance. But additional tuning
might 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 might 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.
-fast selects the following options:
o -xtarget=native sets the hardware target.
If the program is intended to run on a different
target than the compilation machine, follow the -fast
with the appropriate -xtarget= option. For example:
f95 -fast -xtarget=generic ...
o -O5 selects optimization level 5.
o -libmil selects inlining of certain math library
routines.
o -fsimple=2 selects aggressive floating-point
optimizations. This option might be unsuited for
programs requiring strict IEEE 754 standards
compliance.
o -dalign selects generation of faster double word
load/store instructions, and alignment of double and
quad data on their natural boundaries in common
blocks. Using this option might generate nonstandard
Fortran data alignment.
o -xlibmopt selects linking the optimized math library.
o -depend=yes selects dependence analysis to better
optimize DO loops. (This option is always selected
for optimization levels -O3 and greater.)
o -fns selects faster (but nonstandard) handling of
floating-point arithmetic exceptions and gradual
underflow.
o -ftrap=common selects trapping on common floating-
point exceptions (this is the default for f95).
o -pad=local selects local padding to improve use of
cache. (SPARC)
o -xvector=lib selects the vectorized math library.
(SPARC)
o -fround=nearest is selected because -xvector and
-xlibmopt require it.
o -nofstore cancels forcing expressions to have the
precision of the result. (x86)
o -xregs=frameptr on x86 allows the compiler to use the
frame-pointer register as a general-purpose register.
Be sure to read the discussion of -xregs=frameptr
especially when compiling mixed C, Fortran, and C++
source codes. Specify -xregs=no%frameptr after -fast
and the frame pointer register will not be used as a
general purpose register. (x86)
Note that this selection of component option flags is
subject to change with each release of the compiler.
For details on the options set by -fast, see the
Fortran User's Guide.
To determine the expansion of -fast on a running
system, execute the command
f95 -fast -dryrun |& grep ###
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 flag and disables the
-xlibmopt selected by -fast.
Because -fast selects
-dalign -fns -fsimple=2
programs compiled with this option 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.
Also, because -fast selects -xlibmopt and -xvector=lib,
default rounding mode, -fround=nearest, is assumed and
required when using -fast.
For separate compile and link steps: if you compile
with -fast, then be sure to link with -fast.
-fixed
Assume fixed-format source input.
Interpret all source files as Fortran 95 fixed-format.
Overrides the file suffix.
-flags
Synonym for -help.
-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.
Fused multiply-adds eliminate the intermediate rounding
step between the multiply and the add. Consequently,
programs may produce different results when compiled
with -fma=fused, although precision will tend to be
increased rather than decreased.
-fnonstd
Initialize floating-point hardware to nonstandard
preferences
This option is a macro for the combination
-fns -ftrap=common
which initializes the floating-point hardware to:
o Abort on exceptions
o Flush denormalized numbers to zero if it will
improve speed
To be effective, compile the main program with this
flag.
See -fns for a information on underflow and handling of
denormalized numbers.
The -fnonstd option enables hardware traps 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
aborts. See ieee_handler(3m), ieee_functions(3m), the
Numerical Computation Guide, and Fortran Programming
Guide for more information.
-fns[={yes|no}]
Select nonstandard floating point
The default, -fns=no, utilizes standard floating-point
mode.
Optional use of =yes or =no provides a way of toggling
the -fns flag following some other macro flag that
includes -fns, such as -fast.
-fns is the same as -fns=yes.
-fns=yes selects nonstandard floating-point.
-fns=no selects standard floating-point. (Default)
-fast selects -fns.
On SPARC platforms, 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 platforms
that do not support gradual underflow and subnormal
numbers in hardware, use of this option can
significantly improve the performance of some programs.
On x86 platforms, this option is enabled only for
Pentium III and Pentium 4 processors (sse or sse2).
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.
Warning: When nonstandard mode is enabled, floating
point arithmetic can produce results that do not
conform to the requirements of the IEEE 754 standard.
See the Numerical Computation Guide and the Fortran
User's Guide for more information.
This option is effective only if used when compiling
the main program.
-fpover[={yes|no}]
Detect floating-point overflow in formatted input.
With -fpover=yes specified, the I/O library will detect
floating-point overflows in formatted input and cause
an arithmetic exception. Combine with -ftrap to get
full diagnostic information.
The default is no such overflow detection (-fpover=no).
-fpover is equivalent to -fpover=yes.
-fpp Force preprocessing of input files with fpp.
Pass all the input source files listed on the command
line through the fpp preprocessor, regardless of file
extension. (Files with .F90, .F95, .F, F03, extension
are automatically preprocessed by fpp. See also -xpp.)
-fprecision=p
(x86) Initialize non-default floating-point rounding
precision mode.
On x86, sets the floating-point precision mode to
either single, double, or extended.
When p is single or double, this flag causes the
rounding precision mode to be set to single or double
precision respectively at program initiation. When p
is extended or the -fprecision flag is not used, 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, but is ignored
if compiling for 64-bit platforms (-m64), or SSE2-
enabled processors (-xarch=sse2). -fprecision is
ignored on SPARC platforms.
-free
Assume free-format source input.
Interpret all source files as Fortran 95 free-format.
Overrides the file suffix.
-fround=r
Select the IEEE rounding mode in effect at startup.
r must be one of:
nearest, tozero, negative, positive.
The default is -fround=nearest.
When r is tozero, negative, or positive this flag
causes the rounding direction mode to be set to round-
to-zero, round-to-negative-infinity, or round-to-
positive-infinity respectively when the program begins
execution. When r is nearest or the -fround flag is
not used, the rounding direction mode is not altered
from its initial value (round-to-nearest by default).
This option is effective only if used when compiling
the main program.
Note that compiling with -xvector or -xlibmopt require
default rounding. Programs that link with libraries
compiled with either -xvector or -xlibmopt or both must
ensure that default rounding is in effect.
-fsimple[=n]
Select floating-point optimization preferences
Allow the optimizer to make simplifying assumptions
concerning floating-point arithmetic.
If n is present, it must be 0, 1, or 2.
The defaults are:
With no -fsimple, f95 uses -fsimple=0
With only -fsimple, f95 uses -fsimple=1
-fsimple=0
Permit no simplifying assumptions. Preserve strict
IEEE 754 conformance.
-fsimple=1
Allow conservative simplifications. The resulting
code does not strictly conform to IEEE 754, but
numeric results of most programs are unchanged.
With -fsimple=1, the optimizer can assume the
following:
IEEE 754 default rounding/trapping modes do not
change after process initialization.
Computations producing no visible result other
than potential floating point exceptions might be
deleted.
Computations with Infinity or NaNs as operands
need not propagate NaNs to their results; e.g.,
x*0 might 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, permits aggressive
floating-point optimizations that can cause many
programs to produce different numeric results due to
changes in rounding. Also, enables use of SIMD
instructions to compute reductions when compiling
with -xvector=simd.
In particular, the Fortran standard rule requiring
compilers to honor explicit parentheses around
subexpressions to control expression evaluation
order might 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 might
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 tries not
to introduce a situation that could produce a
floating-point exception in a program that otherwise
produces none.
-fast selects -fsimple=2.
-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. The default is -fstore. However,
the -fast option includes -nofstore to disable this
option. Follow -fast with -fstore to turn this option
back on.
-ftrap=t
Set floating-point trapping mode
This option sets the IEEE floating-point trapping that
is in effect at startup.
t is a comma-separated list that consists of one or
more of the following:
%all, %none, common, [no%]invalid, [no%]overflow,
[no%]underflow, [no%]division, [no%]inexact.
The f95 default is -ftrap=common. (Note that the
default with f77 was -ftrap=%none.)
This option 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.
Example: Set all traps except inexact:
-ftrap=%all,no%inexact
The meanings are the same as for the ieee_flags
function:
Value Meaning
[no%]division [Do not] Trap on division by zero.
[no%]inexact [Do not] Trap on inexact result.
[no%]invalid [Do not] Trap on invalid operation.
[no%]overflow [Do not] Trap on overflow.
[no%]underflow [Do not] Trap on underflow.
%all Trap on all the above.
%none Trap on none of the above.
common Trap on invalid, division by zero, and
overflow.
Note that the [no%] form of the option is used only to
modify the meanings of the %all or common value and
must be used with one of these values, as shown in the
exam ple. The [no%] form of the option by itself does
not explicitly cause a particular t rap to be disabled.
To be effective this option must be used when compiling
the main program.
-G Produce a shared object rather than a dynamically
linked executable. This option is passed to ld and
cannot be used with the -dn option.
When you use the -G option, the compiler does not pass
any default -l options to ld. If you want the shared
library to have a dependency on another shared library,
you must pass the necessary -l option on the command
line.
If you are creating a shared object by specifying -G
along with other compiler options that must be
specified at both compile time and link time, make sure
that those same options are also specified when you
link with the resulting shared object.
When you create a shared object, all the object files
that are compiled for 64-bit SPARC architectures must
also be compiled with an explicit -xcode value as
documented under the description of -xcode.
-g Compile for debugging and performance analysis.
Produce additional symbol table information for
debugging with dbx(1) or the Studio Debugger, and for
analysis with the Studio Performance Analyzer,
analyzer(1).
Although some debugging is possible without specifying
-g, the full capabilities of dbx are only available to
those objects compiled with -g.
To use the full capabilities of the Oracle Solaris
Studio 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.)
The commentary messages generated with -g describe the
optimizations and transformations the compiler made
while compiling your program. You must use er_src(1),
er_print(1), or the performance analyzer, analyzer(1)
to view the commentary messages.
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.
-h nm
Specify the name of the generated dynamic shared
library
If the library has an internal name, then whenever the
executable is run, the linker must find a library with
the same internal name; the file can be in any library
search path. If the library has no internal name, then
the linker must find a library with the same path as
when it was generated. Having an internal name allows
more flexibility at runtime.
Remarks:
o The space between the -h and nm is optional.
o -hnm is meaningless without -G.
o -hnm is a linker option.
o The names after -h and -o are usually the same.
o -hnm facilitates versions for dynamic libraries.
See the Oracle Solaris OS Linker and Libraries Guide.
-help
List the f95 command-line options.
See also -xhelp.
-Ipath
Add path to the include file search path.
Insert directory path path at the start of the include
file search path. A space is allowed between -I and
path.
The include file search path is the list of directories
searched for include files. This search path is used
by:
o The preprocessor directive #include
o The f95 statement INCLUDE
Example: To search for include files in /usr/applib:
f95 -I/usr/applib growth.F
To invoke the preprocessor, you must be compiling
source files with .F .F90 .F95 .F03 suffixes.
The search path is also used to search for MODULE
files.
The -Ipath search path is used while searching relative
path names on INCLUDE statements, not absolute path
names. The search order for relative path names is:
1. The directory containing the source file
2. Directory paths named in -I options
3. Directories in the default list of the compiler
4. /usr/include
-i8 (There is no -i8 option.)
Use -xtypemap=integer:64 to specify 8-byte INTEGER with
this compiler.
-inline={%auto|[no%]function|...}
Enable/disable inlining of specified user-written
routines.
Optimize by inlining the specified user-written
routines named in the comma-separated list of functions
and subroutines.
The argument list can include the string %auto to
enable automatic inlining at optimization levels -O4 or
higher. Automatic inlining is normally turned off when
explicit inlining is specified on the command line by
-inline.
If you prefix the name of a routine on the list with
no%, inlining of that routine is inhibited.
For example, to enable automatic inlining while
disabling inlining of a specific routine (gflub), use:
-O5 -inline=%auto,no%gflub
An empty list turns off automatic inlining
-fast -inline= sourcefile.f95
Here, -fast implies -O5, which enables automatic
inlining. However, the -inline= with an empty list
disables it.
Only routines in the file being compiled are
considered. The optimizer decides which of these
routines are appropriate for inlining.
A routine is not inlined if any of the following
conditions apply, with no warnings:
o Optimization is less than -O3
o The routine cannot be found.
o Inlining it is not profitable or safe.
o The source is not in the file being compiled unless
-xipo is also specified.
-iorounding[={compatible | processor-defined}]
Set rounding mode for formatted input/output.
Sets the ROUND= specifier globally for all formatted
input/output.
With -iorounding=compatible, the value resulting from
data conversion is the closer of 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.
Specifying -iorounding without an argument is
equivalent to -iorounding=compatible.
-Kpic
Synonym for -pic
-KPIC
Synonym for -PIC
-keeptmp
Retains the temporary files that are created during
compilation.
-Lpath
Add path to list of directory paths to search for
libraries.
path is added to the start of the search list. A space
between -L and path is optional.
Note: Do not use the -Lpath option to specify /usr/lib
or /usr/ccs/lib, since they are searched by default,
and including them here prevents using the unbundled
libm.
-lx Add library libx.a to the linker's list of search
libraries.
Direct the loader to link with object library libx.a,
where x is a string. See ld(1).
Example: -lsumex links in the library libsumex.a
Order on the Command Line: Place -lx options after any
.f, .F, or .o files. If you call functions in libx, and
they reference functions in liby, then place -lx before
-ly.
Search Order for -lx files: The linker searches for
libraries in several locations. For details, see the
chapter, "Libraries," in the Fortran Programming Guide.
See also ld(1).
-libmil
Inline selected libm math library routines for
optimization.
Some of the simpler library routines can be inlined by
the compiler. This option inlines library calls
depending on the floating-point options and platform
currently being used.
-library=sunperf
Link with the Oracle Solaris Studio supplied
performance libraries.
-loopinfo
Show which loops are parallelized
Show which loops are parallelized and which are not.
This option is normally for use with the
-autopar option. It generates a list of messages on
standard error.
-Mpath
Specify MODULE directory, archive, or file.
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.
A .a archive 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 USE ME 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 flag
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.
Directories named in -I path will be searched for
module files if the files are not found in any of the
other locations that are searched.
A space between the -M and the path is allowed. For
example, -M /home/siri/PK15/Modules
On Oracle 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.
-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 Oracle 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 Oracle Solaris, -m32 is the default. On Linux
systems supporting 64-bit programs , -m64 -xarch=sse2
is the default.
See also -xarch.
-moddir=path
Specify the path to a directory where the compiler will
write .mod MODULE files. The path can also be specified
by using the MODDIR environment variable. If both are
specified, this option flag takes precedence.
The default directory for writing .mod files is the
current directory.
-mt[={yes|no}]
Use this option to compile and link multithreaded code
using the Oracle Solaris threads or POSIX threads API.
The -mt=yes option assures that libraries are linked in
the appropriate order.
This option passes -D_REENTRANT to the preprocessor.
header file and compile with the
On Linux platforms, only the POSIX threads API is
available. (There is no libthread on Linux platforms.)
Consequently, -mt=yes on Linux platforms adds -lpthread
instead of -lthread. To use POSIX threads on Linux
platforms, compile with -mt.
Note that when compiling with -G, neither -ltread nor
-lpthread are automatically included by -mt=yes. You
will need to explicitly list these libraries when
building a shared library.
The -xopenmp option (for using the OpenMP shared-memory
parallelization API) includes -mt=yes automatically.
If you compile with -mt=yes and link in a separate
step, you must use the -mt=yes option in the link step
as well as the compile step. If you compile and link
one translation unit with -mt=yes, you must compile and
link all units of the program with -mt=yes
-mt=yes is the default behavior of the compiler. If
this behavior is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
-native
Optimize for the host system.
The -native option is a synonym for the -xtarget=native
option.
-noautopar
Cancel -autopar on the command line.
Cancel automatic parallelization of loops invoked by
-autopar on the command line.
-nodepend
Cancel -depend in command line
Cancel dependence analysis invoked by a -depend option
appearing earlier in the command line.
-nofstore
(x86) Cancel -fstore on command line
Cancels forcing expressions to have the precision of
the destination variable invoked by -fstore.
-nofstore is invoked by -fast. -fstore is the usual
default.
-nolib
Do not link with system libraries.
Do not automatically link with any system or language
library; that is, do not pass any default -lx options
to ld. The default is to link such libraries into
executables automatically, without users specifying
them on the command line.
The system and language libraries are required for
final execution. It is your responsibility to link them
in manually. This option provides you complete control
(and responsibility).
The -nolib option makes it easier to link these
libraries statically.
-nolibmil
Cancel -libmil on command line
Use with -fast to disable inlining of libm math
routines:
demo% f95 -fast -nolibmil ...
-noreduction
Cancel -reduction on command line
-reduction is used along with parallelization options.
This option cancels a -reduction appearing earlier on
the command line.
-norunpath
Do not build a runtime library search path into the
executable
If an executable file uses shared libraries, then the
compiler normally builds in a path that tells the
runtime linker where to find those shared libraries.
The path depends on the directory where you installed
the compiler. The -norunpath option prevents that path
from being built into 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
-R.
-O[n]
Specify optimization level (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 can be significantly improved
when compiled with an explicit optimization level.
Each -On level includes the optimizations performed at
the levels below it. Generally, the higher the level of
optimization, the better the runtime performance.
However, higher optimization levels can result in
increased compilation time and larger executable files.
There are five optimization levels that you can specify
with -On. The actual optimizations performed by the
compiler at each level could change with each compiler
release.
Use of -O (which implies -O3) or -fast (which implies
-O5) is recommended for most programs.
The -g option can be used with optimization.
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.
-O Optimize at the level most likely to give close to
the maximum performance for many realistic
applications (equivalent to -O3).
-O1 Do only the basic local optimizations (peephole).
-O2 Do basic local and global optimization. This level
usually gives minimum code size.
-O3 Adds global optimizations at the function level.
In general, this level, and -O4, usually result in
the minimum code size when used with the -xspace
option. Automatically turns on -depend data
dependence analysis.
-O4 Adds automatic inlining of functions in the same
file. -O4 results in larger code unless combined
with -xspace.
See -inline to control which routines are inlined.
-O5 Does the highest level of optimization, suitable
only for the small fraction of a program that uses
the largest fraction of computer time. Uses
optimization algorithms that take more compilation
time or that do not have as high a certainty of
improving execution time. Optimization at this
level is more likely to improve performance if it
is done with profile feedback. See
-xprofile=collect|use.
Interactions:
If you use -g and the optimization level is -O3 or
lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-
call optimization and back-end inlining are
disabled.
For more information, see Debugging a Program With
dbx.
See also: -fast, -xprofile=p, csh(1) man page
-o filename
Names the output file filename, instead of the default
a.out. filename cannot be the same as sourcefile since
cc does not overwrite the source file.
filename must have an appropriate suffix. When used
with -c, filename specifies the target .o object file;
with -G it specifies the target .so library file. This
option and its argument are passed to ld.
-onetrip
Enable one-trip DO loops.
Compile DO loops so they are performed at least once if
reached.
Fortran 95 DO loops are not performed at all if the
upper limit is smaller than the lower limit, unlike
some legacy implementations of Fortran.
-openmp
Synonym for -xopenmp
-p (Obsolete) Compile for profiling with prof.
Prepare object files for profiling with prof(1). This
option makes profiles by procedure, showing the number
of calls to each procedure and the percent of time used
by each procedure.
For separate compile and link steps, and if you compile
with -p, then be sure to link with -p.
This option is now obsolete. Use -g and the performance
analyzer analyzer(1) instead.
-pad[=p]
Insert padding for efficient use of cache.
This option inserts padding between arrays or character
strings if they are:
o Static local and not initialized, or
o In common blocks
For either one, the arrays or character strings can not
be equivalenced.
If =p is present, it must be one of the following (no
spaces):
%none: No padding is done.
local: Pad local variables
common: Pad variables in common blocks
local,common: Both local and common padding is done.
local and common can appear in any order.
Defaults:
The compiler default is to do no padding.
Specifying -pad, without a value is equivalent to
-pad=local,common
The program must conform to the following
restrictions:
o If -pad=common is specified for a file that
references a common block, it must be specified
for all files that reference that common block.
o With -pad=common specified, the layout of
variables in the same common block in different
program units must be the same except for the
names of the variables.
o Padding is dependent on the setting of -xcache.
All files must be compiled with the same -xcache
settings when -pad=common is used.
o Do not specify -pad=common if the program
overindexes arrays in common blocks. The padding
inserted between arrays by the compiler will
interfere with the assumed layout of the data, and
will cause the array references to fail in
unpredictable ways.
o EQUIVALENCE declarations involving common block
variables will cause warning messages that padding
has been inhibited by EQUIVALENCE when compiled
with -pad=common. These arrays will not be
padded.
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.
-pg Prepares the object code to collect data for profiling
with gprof(1). (-xpg is a synonym for -pg)
Invokes a runtime recording mechanism that produces a
gmon.out file (at normal termination).
Note: There is no advantage compiling with -xprofile if
you specify -xpg. The two do not prepare or use data
provided by the other.
Profiles are generated by using prof or gprof on 64 bit
Oracle Solaris platforms or just gprof on 32 bit Oracle
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 Oracle 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 -xpg and using gprof(1).
The latest Oracle Solaris releases do not include
system libraries compiled with -p. As a result,
profiles collected on current Oracle Solaris platforms
do not include call counts for system library routines.
Note: On x86 systems, -xpg is incompatible with
-xregs=frameptr because the gprof runtime library
requires a valid frame pointer to determine the return
address of a profiled routine. Note also that
compiling with -fast on x86 systems will invoke
-xregs=frameptr. Compile with the following instead:
-fast -xregs=no%frameptr -xpg
NOTE: 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.
For separate compile and link steps, if you compile
with -pg, then link with -pg.
Warning: Binaries compiled with -xpg for gprof
profiling should not be used with binopt(1), as they
are incompatible and can result in internal errors.
-pic Compile position-independent code for shared library.
On SPARC, this is equivalent to -xcode=pic13
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.
-PIC On SPARC, this is equivalent to -xcode=pic32
On x86, -PIC is identical to -pic
-Qoption pr ls
Pass option list ls to the compilation phase pr.
This option is used primarily by customer service.
-qp Synonym for -p.
-R list
Build library search paths into executable
With this option, the linker, ld(1), adds a list of
library search paths into the executable file.
list is a colon-separated list of directories used to
specify library search paths to the runtime linker. The
list is added to the default list that f95 passes to
the linker.
The blank between -R and list is optional.
Multiple instances of this option are concatenated
together, with each list separated by a colon.
Use this option if you want to export an executable
that can run without any special option for paths to
your dynamic libraries.
Building an executable with this option adds paths to a
default path that is always searched last:
<installpath>/lib
The default library search order can be seen by using
the -dryrun option and examining the -Y option of the
ld invocation.
-r8const
Promote single-precision constants to REAL*8 constants.
All single precision literal constants are promoted to
REAL*8. Double-precision constants (REAL*8) are not
promoted.
This flag applies only to constants. Use -xtypemap to
promote both constants and variables.
Use this flag carefully. It could cause interface
problems when calling a routine with a REAL*4 literal
constant as an actual argument where a REAL*4 value is
expected. It could also cause problems with programs
reading unformatted data files written by a write
statement with a literal REAL*4 constant on its I/O
list.
-recl=a[,b]
Set default output record length.
Set the default record length (in characters) for
either or both preconnected units output (standard
output) and error (standard error).
This option must be specified using one of the
following forms:
-recl=out:N
-recl=error:N
-recl=out:N1,error:N2
-recl=error:N1,out:N2
-recl=all:N
where N, N1, N2 are all positive integers in the range
from 72 to 2147483646.
out refers to standard output, error to standard error,
and all sets the default record length to both.
The default is -recl=all:80.
This option is only effective if the program being
compiled has a Fortran main program.
-reduction
Parallelize reduction operations in loops
Analyze loops for reduction in automatic
parallelization. To enable parallelization of reduction
loops, specify both -reduction and -autopar.
Example: demo% f95 -autopar -reduction any.f
A loop that transforms the elements of an array into a
single scalar value is called a reduction operation.
For example, summing the elements of a vector is a
typical reduction operation. Although these operations
violate the criteria for parallelization, 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 f95.
If you specify -reduction without -autopar, the
compiler issues a warning.
On a single-processor system, the generated code
usually runs more slowly.
There is always potential for roundoff error with
reduction.
-S Compile and only generate assembly code.
Compile the named programs and leave the assembly
language output on corresponding files suffixed .s (no
.o file is created).
-s Strip the symbol table from the executable file.
This option makes the executable file smaller and more
difficult to reverse engineer. However, this option
prevents debugging.
-silent
Suppress compiler messages.
Normally, f95 does not issue messages, other than error
diagnostics, during compilation. This option is
provided only for compatibility with older scripts and
makefiles. -silent is the default and its use is
redundant.
-stackvar
Force all local variables to be allocated on the stack.
Allocates all the local variables and arrays in
routines onto the memory stack unless otherwise
specified. This option makes these variables automatic
rather than static and provides more freedom to the
optimizer when parallelizing loops with calls to
subprograms.
Use of -stackvar is required with explicitly
parallelized loops containing subprogram calls, and
recommended for any of the parallelization options.
-stackvar is automatically included when -xopenmp is
used. See the Parallelization chapter in the Fortran
Programming Guide for additional information on when -
stackvar should and should not be used.
Variables and arrays are local, unless they are:
o Arguments in a SUBROUTINE or FUNCTION statement
(already on stack)
o Global items in a COMMON or SAVE, or STATIC
statement
o Initialized items in a type statement or a DATA
statement, such as:
REAL X/8.0/ or DATA X/8.0/
Putting large arrays onto the stack with -stackvar can
overflow the stack causing segmentation faults.
Increasing the stack size might 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 for the main stack is about 8
Megabytes. The default helper thread stack size is 4
Megabytes on 32-bit platforms and 8 Megabytes on 64-bit
platforms.
The limit command (with no parameters) shows the
current main stack size.
Use the limit shell command to set the size (in
Kilobytes) of the main thread stack. For example, to
set the main stack size to 64 Megabytes, use this
command:
% limit stacksize 65536
You can set the stack size to be used by each slave
thread by giving the STACKSIZE environment variable a
value (in Kilobytes):
% setenv STACKSIZE 8192
sets the stack size for each slave thread to 8 Mb.
The STACKSIZE environment variable also accepts
numerical values with a suffix of either B, K, M, or G
for bytes, kilobytes, megabytes, or gigabytes
respectively. The default is kilobytes.
See the Fortran Programming Guide chapter on
parallelization for details.
See also -xcheck=stkovf to enable runtime checking for
stack overflow situations.
-stop_status[={yes|no}]
Enable the STOP statement to return an integer status
value.
The optional argument is either yes or no. The default
is yes.
With -stop_status=yes a STOP statement can contain an
integer constant that will be passed to the environment
as the program terminates. This value will be
available as $status for the C shell or $? for the
Bourne and Korn shells.
The value on the STOP statement can be any positive
integer. The value returned to the shell will be
modulo 256 (in the range 0 to 255).
-temp=dir
Define directory for temporary files.
Set the directory for temporary files used by f95 to be
dir instead of the /tmp directory. This option has
precedence over the TMPDIR environment variable.
-time
Show execution time for each compilation phase.
-traceback[={%none|common|signals_list}]
Issue a stack trace if a severe error occurs in
execution.
The -traceback option causes the executable to issue a
stack trace to stderr, dump core, and exit if certain
signals are generated by the program. If multiple
threads generate a signal, a stack trace will only be
produced for the first one.
To use traceback, add the -traceback option to the
compiler command line when linking. The option is also
accepted at compile-time but is ignored unless an
executable binary is generated. Using -traceback with
-G to create a shared library is an error.
%none or none
disables traceback
common
specifies that a stack trace should be issued if
any of a set of common signals is generated --
sigill, sigfpe, sigbus, sigsegv, and sigabrt.
signals_list
specifies a comma-separated list of names of
signals which should generate a stack trace, in
lower case. The following signals (those that
cause the generation of a core file) can be
caught:
sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe,
sigbus, sigsegv, sigsys, sigxcpu, sigxfsz
Any of these can be preceeded with no% to disable
catching the signal.
For example: -traceback=sigsegv,sigfpe will
produce a stack trace and core dump if either
sigsegv or sigfpe is generated.
If the option is not specified, the default is
-traceback=%none
-traceback without any = sign implies -traceback=common
Note: If the core dump is not wanted, users may set the
coredumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime
performance.
-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.
Portability and mixing Fortran with other languages
might require use of -U.
Calls to intrinsic functions are not affected by this
option.
-Uname
Undefine preprocessor macro name
Removes any initial definition of the preprocessor
macro symbol name created by -Dname on the same command
line, or implicitly placed there by the command-line
driver, regardless of the order the options appear. It
has no affect on any macro definitions in source files.
Multiple -Uname flags may appear on the same line, and
there must be no space between -U and name.
This option applies only to .F, .F90, .F95, and .F03
source files that invoke the fpp or cpp preprocessors.
-u Report on undeclared variables.
Equivalent to specifying IMPLICIT NONE in each
compilation unit. This has the affect of making the
default type of variables undeclared rather than using
standard Fortran implicit typing. This option does not
override any existing IMPLICIT statements or explicit
type statements.
-unroll=n
Enable unrolling of DO loops n times where possible.
n is a positive integer.
n = 1, inhibits all loop unrolling
n > 1, this option suggests to the optimizer that it
unroll loops n times.
If any loops are actually unrolled, then the executable
file is larger.
-use=list
Specify implicit MODULE usage, globally.
list is a comma-separated list of module names or
module file names. Compiling with -use=module_name in
effect adds a USE module_name to each subprogram being
compiled. Similarly, compiling with
-use=module_file_name effectively adds to each
subprogram being compiled a USE module_name for each of
the modules contained in the module_file_name file.
-V Show name and version of each compilation phase.
-v Verbose mode - show compilation details
Like -V but also details the options, macro flag
expansions, and environment variables used by the
driver.
-vax=v
Specify choice of VAX VMS Fortran extensions enabled.
v must be one of the following suboptions or a comma-
delimited list of a selection of these.
blank_zero: interpret blanks in formatted input as
zeros on internal files.
debug: interpret lines starting with the
character 'D' to be regular Fortran
statements rather than comments, as in
VMS Fortran.
rsize: interpret unformatted record size to be
in words rather than bytes.
struct_align: layout components of a VAX structure in
memory as in VMS Fortran, without
padding. This option flag replaces the
f77 -xl flag. Note: this can cause data
misalignments ("bus error") and should be
used with -xmemalign to avoid such
errors.
%all: enable all these VAX VMS features.
(Default.)
%none: disable all these VAX VMS features.
Sub-options can be individually selected or turned off
(by preceding with no%).
Example:
-vax=debug,rsize,no%blank_zero
The default is -vax=%none. If -vax is specified
without any suboptions, it is equivalent to -vax=%all.
-vpara
Show parallelization warning messages
Issues warnings about potential parallel programming
related problems that may cause incorrect results with
with -xopenmp and OpenMP API directives.
Warnings are issued when the compiler detects a
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.
No warnings appear if all parallelization directives
are processed without issues.
Example,
f95 -xopenmp -vpara any.f
Note: Oracle Solaris Studio compilers support OpenMP
3.1 API parallelization. See the OpenMP API User's
Guide for information on migrating to the OpenMP API.
-Wc,arg
Passes the argument arg to component c. Each argument
must be separated from the preceding by only a comma.
(A comma can be part of an argument by escaping it by
an immediately preceding backslash (\) character; the
backslash is removed from the resulting argument.) All
-W arguments are passed after the regular command-line
arguments.
c can be one of the following:
a Assembler: (fbe), (gas)
c f95 code generator: (cg)(SPARC)
d f95 driver
l Link editor (ld)
m mcs
O (Capital letter 'O') Interprocedural
optimizer
o Postoptimizer
p Preprocessor (cpp)
0 (The number zero) Compiler (f90comp)
2 Optimizer: (iropt)
Note: You cannot use -Wd to pass the f95 options listed
in this man page to the Fortran compiler.
For example, -Wa,-o,objfile passes -o and objfile to
the assembler, in that order; also -Wl,-I,name causes
the linking phase to override the default name of the
dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool
with respect to the other specified command line
options may change.
-w[{0|1|2|3|4}]
Show or suppress warning messages.
-w suppresses warning messages from the compiler.
-w0 shows just error messages.
-w1 shows errors and warnings. (This is the default.)
-w2 shows errors, warnings, and cautions.
-w3 shows errors, warnings, cautions, and notes.
-w4 shows errors, warnings, cautions, notes, and
comments.
If you specify two options, and the second one
overrides all or part of the first one, the compiler
issues a warning.
-Xlinker arg
Pass arg to the linker, ld. Equivalent to -z arg.
-Xlist[z]
Produce listings and do global program checking.
Find potential programming bugs. Invokes an extra
compiler pass to check for consistency in calls and
common across the global program. Generates line-
numbered source code listing with cross references.
Diagnostic messages from -Xlist are warnings and do not
prevent compiling and linking.
Be sure to correct all syntax errors first; -Xlist
might produce unpredictable reports when run on a
source program with syntax errors.
Output is to a file with a name like the first file
name but with a .lst extension.
Example: Errors, listing, and xref to file1.lst
demo% f95 -Xlist file1.f file2.f
Use the -Xlist options to check for interprocedural
problems, but only after all other compiler errors and
warnings have been resolved.
Summary of -Xlist Suboptions
-Xlist Default: listings, errors, xref
-Xlistc Call graphs and errors.
-XlistE Errors only (no xref or listings)
-Xlisterr Suppress all -Xlist error messages
-Xlisterr[n] Suppress -Xlist error message n.
-Xlistf Errors, listing, and cross references,
but no object files compiled.
-Xlisth Terminate if errors detected.
-XlistI Check include files also
-XlistL Listings only (no xref)
-Xlistl[n] Page length is n lines
-XlistMP (SPARC) Check OpenMP directives.
-Xlisto nm Output to nm instead of to file.lst
-Xlists Suppress unreferenced names from cross-
reference table.
-Xlistvn Set checking level to n (1,2,3, or 4) -
default is 2
-Xlistw[nnn] Set output line width to n; default is
79
-Xlistwar Suppress all -Xlist warning messages
-Xlistwar[n] Suppress -Xlist warning message n.
-XlistX Cross-reference only (no listings)
See the Fortran Programming Guide for details.
-xaddr32[={yes|no}]
(x86/x64 only) The -xaddr32=yes compilation flag
restricts the resulting executable or shared object to
a 32-bit address space.
An executable that is compiled in this manner results
in the creation of a process that is restricted to a
32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is
produced.
If the -xaddr32 option is not specified, -xaddr32=no is
assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and
only on Oracle Solaris platforms supporting
SF1_SUNW_ADDR32 software capability.
Since Linux kernel does not support addres space
limitation this option is not available on Linux. The
-xaddr32 option is ignored on Linux.
When linking, if a single object file was compiled with
-xaddr32=yes the whole output file is assumed to be
compiled with -xaddr32=yes.
A shared object that is restricted to a 32-bit address
space must be loaded by a process that executes within
a restricted 32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32
software capabilities definition, described in the
Linker and Libraries Guide.
-xalias[=type_list]
Specify degree of aliasing to be assumed by the
compiler.
Nonstandard programming techniques can introduce
situations that interfere with the compiler's
optimization strategies. In particular, the use of
overindexing, pointers, and passing global or non-
unique variables as subprogram arguments, introduce
ambiguous aliasing situations that prevent the compiler
from applying certain optimizations, and can introduce
ambiguities that could result in unexpected results.
See the Fortran User's Guide for more information about
aliasing.
Use the -xalias flag to inform the compiler about the
ways in which the program deviates from the aliasing
requirements of the Fortran standard.
The flag may appear with or without a list. The
keywords on the list are 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:
dummy Dummy (formal) subprogram parameters can
alias each other and global variables.
no%dummy (Default). Usage of dummy parameters follows
the Fortran standard and may 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) A reference to an element of an array in
a COMMON block could refer to any element in
a COMMON block or equivalence group.
(b) 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.
(c) Elements of a sequence derived type are
treated as if they were COMMON blocks.
(d) 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.
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.
The default, when -xalias is not specified on the
compiler command line, corresponds to:
-xalias=no%dummy,craypointer,no%actual,no%overindex,\
no%ftnpointer
Specifying -xalias without a list gives the best
performance for most programs that do not violate
Fortran aliasing rules, and corresponds to:
-xalias=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.
See the chapter on Porting in the Fortran Programming
Guide for further details.
-xannotate[={yes|no}]
(Oracle Solaris) Instructs the compiler to create
binaries that can later be used by the optimization and
observability tools binopt(1), code-analyzer(1),
discover(1), collect(1), and uncover(1).
The default is -xannotate=yes. Specifying -xannotate
without a value is equivalent to -xannotate=yes.
For optimal use of the optimization and observability
tools, -xannotate=yes must be in effect at both
compile and link time.
Compile and link with -xannotate=no to produce slightly
smaller binaries and libraries when optimization and
observability tools will not be used.
This option is not available on Linux systems.
-xarch=isa
Specifies the target architecture instruction set
(ISA).
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. However, use of this
option can affect the portability of a binary program.
See the Notes and Warnings sections at the end of this
entry.
Note: The compiler and linker will mark .o files and
executables that require a particular instruction set
architecture (ISA) so that the executable will not be
loaded at runtime if the running system does not
support that particular ISA.
Note: Use the -m64 or -m32 option to specify the
intended memory model, LP64 (64-bits) or ILP32 (32-
bits) respectively. The -xarch flag no longer
indicates the memory model, except for compatibility
with previous releases, as indicated below.
If you compile and link in separate steps, make sure
you specify the same value for -xarch in both steps.
Values for all platforms:
Value Meaning
generic This option uses the instruction set common
to most processors.
generic64 Compile for good performance on most 64-bit
platforms. (Oracle 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.
native64 Compile for good performance on this system
(Oracle Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for
compatibility with earlier releases.
Values specific to SPARC platforms:
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.
sparc4 Compile for the SPARC4 version of the SPARC-
V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, which includes VIS
1.0, the UltraSPARC-III extensions, which
includes VIS2.0, the fused floating-point
multiply-add instructions, VIS 3.0, and
SPARC4 instructions.
sparcvis Compile for the SPARC-V9 ISA plus VIS.
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.
sparcvis3 Compile for the SPARC-V9 ISA with UltraSPARC
III and VIS 3 extensions.
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, the
fused multiply-add instructions, and the
Visual Instruction Set (VIS) version 3.1
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=sparcfmaf in
conjunction with -fma=fused and some
optimization level to get the compiler to
attempt to find opportunities to use the
multiply-add instructions automatically.
sparcima Compile for the sparcima 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, the
SPARC64 VI extensions for floating-point
multiply-add, and the SPARC64 VII extensions
for integer multiply-add.
v9 Is 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 Is equivalent to -m64 -xarch=sparcvis and is
provided for compatibility with earlier
releases.
v9b Is equivalent to -m64 -xarch=sparcvis2 and
is provided for compatibility with earlier
releases.
Notes:
o Legacy 32-bit SPARC instruction set architectures V7
and V8 imply -m32 and cannot be combined with -m64.
o Object binary files (.o) compiled with sparc and
sparcvis can be linked and can execute together, but
only on a sparcvis compatible platform.
o Object binary files (.o) compiled with sparc,
sparcvis, and sparcvis2 can be linked and can execute
together, but only on a sparcvis2 compatible
platform.
For any particular choice, the generated executable
could run much more slowly on earlier architectures.
Also, although quad-precision floating-point
instructions are available in many of these
instruction set architectures, the compiler does not
use these instructions in the code it generates.
Values specific to x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to the pentium_pro
architecture.
sse Adds the SSE instruction set to the
pentium_pro instruction set.
sse2 Supplements the pentium_pro and SSE
instruction sets with the SSE2 instruction
set.
sse3 Supplements the pentium_pro, SSE, and SSE2
instruction sets with the SSE3 instruction
set.
ssse3 Supplements the pentium_pro, SSE, SSE2, and
SSE3 instruction sets with the SSSE3
instruction set.
sse4_1 Supplements the pentium_pro, SSE, SSE2, SSE3,
and SSSE3 instruction sets with the SSE4.1
instruction set.
sse4_2 Supplements the pentium_pro, SSE, SSE2, SSE3,
SSSE3, and SSE4.1 instruction sets with the
SSE4.2 instruction set.
avx Adds the Intel Advanced Vector Extensions.
aes Adds the Intel Advanced Encryption Standard
instruction set. Note that the compiler does
not generate AES instructions automatically
when -xarch=aes is specified unless the
source code includes .il inline code, _asm
statements, or assembler code that use AES
instructions, or references to AES intrinsic
functions.
amdsse4a Uses the AMD SSE4a Instruction set.
amd64 Is equivalent to -m64 -xarch=sse2 (Oracle
Solaris only)
Legacy makefiles and scripts that use
-xarch=amd64 to obtain the 64-bit memory
model need only use -m64.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
SSE architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the SSE2
architecture.
amd64a Is equivalent to -m64 -xarch=sse2a (Oracle
Solaris only)
Note: If any part of a program is compiled or
linked on an x86 platform with -m64, then all
parts of the program must be compiled with
one of these options as well.
For details on the various Intel instruction
set architectures (SSE, SSE2, SSE3, SSSE3,
and so on) refer to the Intel-64 and IA-32
Intel Architecture Software Developer's
Manual
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=generic on SPARC platforms
-xarch=generic on x86/x64 platforms
Interactions:
Although this option can be used alone, it is part of
the expansion of the -xtarget option and can be used
to override the -xarch value that is set by a
specific -xtarget option.
For example, -xtarget=ultra4 expands to
-xarch=sparcvis2 -xcache=64/32/4:8192/128/2
-xchip=ultra4
Warnings:
If this option is used with optimization, the
appropriate choice can provide good performance of
the executable on the specified architecture. An
inappropriate choice, however, might result in
serious degradation of performance or in in a binary
program that is not executable on all intended target
platforms.
-xassume_control[=a[,a]...]
Set parameters to control ASSUME pragmas.
Use this flag to control the way the compiler handles
ASSUME pragmas in the source code.
See the Fortran User's Guide for descriptions of the
ASSUME pragmas.
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.
Assertions such as whether an upcoming branch will be
taken, the range of an integer value or expression, the
trip count of an upcoming DO loop, among others, can be
made with an associated probability or certainty.
The 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 Ignores all ASSUME pragmas.
If not specified on the compiler command-line, the
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.
-xautopar
Synonym for -autopar
-xbinopt={prepare|off}
(SPARC) This option is now obsolete and will be removed
in a future release of the compilers. See -xannotate.
Instructs the compiler to prepare the binary for later
optimizations, transformations and analysis with
binopt(1). This option may be used for building
executables or shared objects. This option must be used
with optimization level -xO1 or higher to be effective.
There is a modest increase in size of the binary when
built with this option on the order of 5%.
If you compile in separate steps, -xbinopt must appear
on both compile and link steps:
example% f95 -o myprog -xbinopt=prepare a.o b.o c.f95
If some source code is not available for compilation,
this option may still be used to compile the remainder
of the code. It should then be used in the link step
that creates the final binary. In such a situation,
only the code compiled with this option can be
optimized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the
size of the executable by including debugging
information. The default is -xbinopt=off.
-xcache=c
Define cache properties for use by optimizer.
c must be one of the following:
o generic
o native
o s1/l1/a1[/t1]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, are defined as follows:
si The size of the data cache at level i, in kilobytes
li The line size of the data cache at level i, in bytes
ai The associativity of the data cache at level i
ti The number of hardware threads sharing the cache at
level i The ti parameters are optional. A value of 1
is used if not present.
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; its primary use
is to override a value supplied by the -xtarget option.
The -xcache values are:
generic
Define the cache properties for good performance
on most platforms. This is the default.
native
Define the cache properties for good performance
on this host platform.
s1/l1/a1[/t1]
Define level 1 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]
Define levels 1 and 2 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
Define levels 1, 2, and 3 cache properties.
-xcheck=v
Perform special run-time checks.
v may be chosen from:
%all %none stkovf no%stkovf init_local no%init_local
%all turns on all the special run-time checks, while
%none turns them all off. The default (when -xcheck is
not specified on the command line) is -xcheck=%none.
The suboptions may be specified in a comma-delimited
list, as in:
-xcheck=no%stkovf,init_local
-xcheck=stkovf
Detect stack overflow at runtime. Compiling with
-xcheck=stkovf generates code at each routine entry
to test for thread stack overflow.
-xcheck=no%stkovf disables stack overflow checking.
The default is to do no runtime stack overflow
checking.
If a stack overflow is detected, a SIGSEGV fault
will be raised.
Note that compiling with -xcheck=stkovf does not
guarantee that all stack overflow situations will
be detected since they can occur in routines not
compiled with this option. Undetected stack
overflow can cause data corruption in a neighboring
thread's stack.
-xcheck=init_local
Perform special initialization of local variables.
With this option the compiler initializes local
variables to a value that is likely to cause an
arithmetic exception if it is used before it is
assigned by the program. Memory allocated by the
ALLOCATE statement will also be initialized in this
manner.
Module variables, STATIC and SAVE local variables,
and variables in COMMON blocks are not initialized.
no%init_local disables this initialization and is
the default.
See the C User's Guide description of this option
for a list of the predefined values used by the
compiler to initialize variables.
-xchip=c
Specify target processor for optimizer.
This option specifies instruction timing properties by
specifying the target processor.
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
Some effects are:
o The ordering of instructions, that is, scheduling
o The way the compiler uses branches
o The instructions to use in cases where semantically
equivalent alternatives are available
Common -xchip values on SPARC are identified below.
sparc64vi
Optimize for the SPARC64 VI processor.
sparc64vii
Optimize for the SPARC64 VII processor.
sparc64viiplus
Optimize for the SPARC64 VII+ processor.
ultra Optimize for the UltraSPARC(TM) chip.
ultra2 Optimize for the UltraSPARC II chip.
ultra2e Optimize for the UltraSPARC IIe chip.
ultra2i Optimize for the UltraSPARC IIi chip.
ultra3 Optimize for the UltraSPARC III chip.
ultra3cu Optimize for the UltraSPARC IIIcu chip.
ultra3i Optimize for the UltraSPARC IIIi chip.
ultra4 Optimize for the UltraSPARC IV chip.
ultra4plus
Optimize for the UltraSPARC IV+ chip.
ultraT1 Optimize for the UltraSPARC T1 chip.
ultraT2 Optimize for the UltraSPARC T2 chip.
ultraT2plus
Optimize for the UltraSPARC T2+ chip.
T3 Optimize for the SPARC T3 chip.
T4 Optimize for the SPARC T4 chip.
generic Optimize for good performance on most
supported SPARC platforms. (This is the
compiler default.)
native Optimize for good performance on this
host platform.
The -xchip values on x86 platforms are:
nehalem
Optimize for Intel Nahelem processors.
core2
Optimize for Intel Core2 processors.
amdfam10
Optimize for AMD FAM10 processors.
penryn
Optimize for Intel Pentryn processors.
sandybridge
Optimize for Intel Sandy Bridge processors.
westmere
Optimize for Intel Westmere processors.
opteron
Optimize for AMD Opteron processors.
pentium
Optimize for Pentium processors.
pentium_pro
Optimize for Pentium Pro processors.
pentium3
Optimize for Pentium III processors.
pentium4
Optimize for Pentium 4 processors.
generic
Optimize for most x86 platforms.
native
Optimize for this host processor.
For complete information, see the Fortran User's Guide
-xcode=v
(SPARC) Specify code address space
The following values for -xcode are:
abs32 Generate 32-bit absolute addresses.
Code + data + bss size is limited to 2**32
bytes. This is the default on 32-bit
architectures.
abs44 Generate 44-bit absolute addresses.
Code + data + bss size is limited to 2**44
bytes. Available only on 64-bit architectures.
abs64 Generate 64-bit absolute addresses.
Available only on 64-bit architectures.
pic13 Generate position-independent code (small
model).
Equivalent to -pic. Permits references to at
most 2**11 unique external symbols on 32-bit
architectures, 2**10 on 64-bit.
pic32 Generate position-independent code (large
model).
Equivalent to -PIC. Permits references to at
most 2**30 unique external symbols on 32-bit
architectures, 2**29 on 64-bit.
The default is -xcode=abs32 for 32-bit compilations,
and -xcode=abs44 for 64-bit compilations.
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 on SPARC.
There are two nominal performance costs with
-xcode={pic13|pic32} :
o 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.
o 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 non-sharable, 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:
o If you are building an executable you should
not use -xcode=pic13 or -xcode=pic32.
o If you are building an archive library only for
linking into executables you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building a shared library, start
with -xcode=pic13 and once the GOT size exceed
8,192 bytes, use -xcode=pic32.
o If you are building an archive library for
linking into shared libraries you should just use
-xcode=pic32.
See the Oracle Solaris OS Linker and Libraries
Guide.
-xcommonchk[={yes|no}]
Enable runtime checking of common block
inconsistencies.
This option is provided as a debugging aid for programs
using task common and parallelization (See the task
common pragma.)
Normally, runtime checking for inconsistent task common
declarations is disabled. Compiling with
-xcommonchk=yes enables runtime checking.
If a common block is declared in one source module as a
regular common block, and somewhere else appears in a
task common pragma, the program will stop and a message
pointing to the first such inconsistency issued.
Because runtime checking degrades program performance,
it should only be used during program development and
debugging.
Specifying -xcommoncheck alone is equivalent to
-xcommoncheck=yes
-xdebugformat={stabs|dwarf}
The Oracle Solaris Studio compilers have migrated the
format of debugger information from the "stabs" format
to the "dwarf" format. The default
-xdebugformat=dwarf.
Use this option as a way of accessing either format for
use by 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.
-xdebugformat=stabs generates debugging information
using the stabs standard format.
-xdebugformat=dwarf generates debugging information
using the dwarf standard format.
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 small amount of
debugging information is recorded even without -g, and
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 which could 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 whether an
object or executable file was compiled with "dwarf" or
"stabs" debug information.
-xdepend
Synonym for -depend
-xdryrun
Synonym for -dryrun
-xF Allow function-level reordering by the Studio
Performance Analyzer
Allow the reordering of functions (subprograms) in the
core image using the compiler, the 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 will also pass
a regular file to the linker; see the description of
the -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 might not improve the overall performance of
the application. The Performance Analyzer is part of
Oracle Solaris Studio. See the Performance Analyzer
manual for further information on the analyzer.
-xfilebyteorder=options
Support file sharing between little-endian and big-
endian platforms.
The flag identifies the byte-order and byte-alignment
of unformatted I/O files. options must specify any
combination of the following, but at least one
specification must be present:
littlemax_align:spec
bigmax_align:spec
native:spec
max_align declares the maximum byte alignment for the
target platform. Permitted values are 1, 2, 4, 8, and
16. The alignment applies to Fortran VAX structures and
Fortran 95 derived types that use platform-dependent
alignments for compatibility with C language
structures.
little specifies a "little-endian" file on platforms
where the maximum byte alignment is max_align. For
example, little4 specifies a 32-bit x86 file, while
little16 describes a 64-bit x86 file.
big specifies a "big-endian" file with a maximum
alignment of max_align. For example, big8 describes a
32-bit SPARC file, while big16 describes a 64-bit SPARC
file.
native specifies a "native" file with the same byte
order and alignment used by the compiling processor
platform. The following are assumed to be "native":
PLATFORM "NATIVE" IS
32-bit SPARC big8
64-bit SPARC big16
32-bit x86 little4
64-bit x86 little16
spec, must be a comma-separated list of the following:
%all
unit
filename
%all refers to all files and logical units except those
opened as "SCRATCH", or named explicitly elsewhere in
the -xfilebyteorder flag. %all can only appear once.
unit refers to a specific Fortran unit number opened by
the program.
filename refers to a specific Fortran file name opened
by the program.
Examples:
-xfilebyteorder=little4:1,2,afile.in,big8:9,bfile.out,12
-xfilebyteorder=little8:%all,big16:20
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 with this release, Oracle Solaris Studio
sotware now supports REAL*16 data on x86 platforms.
Unformatted files containing REAL*16 data can now be
used on X86 platforms.
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.
-xhasc[={yes|no}]
Treat Hollerith constant as character string in actual
argument lists.
With -xhasc=yes the compilers treat as character
strings Hollerith constants appearing as an actual
argument in a subprogram call. This is the default and
complies with the Fortran 77 standard.
With -xhasc=no Hollerith constants are treated as
typeless values in subprogram call lists.
This flag is provided to aid porting older Fortran
programs. Compile routines calling subprograms with
Hollerith constants with -xhasc=no if the called
subprogram expects that argument as INTEGER or any
other type other than CHARACTER.
-xhelp=flages
Show summary of compiler options.
-xhelp=flags is a synonym for -help.
-xhwcprof[={enable|disable}]
(SPARC) Enable compiler support for dataspace
profiling.
When -xhwcprof is 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 now the default with
this release of the Oracle Solaris Studio compilers.
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:
example% f95 -c -O -xhwcprof -g example.f
For more information on hardware counter-based
profiling, see the Performance Analyzer manual.
-xia[={widestneed|strict}]
Enable interval arithmetic extensions and set a
suitable floating-point environment.
Interval arithmetic is an extension to the numerical
computation techniques in Fortran 95. For further
information, see the Fortran 95 documentation.
-xia is a macro flag that expands as follows:
-xia and -xia=widestneed expand to:
-xinterval=widestneed -ftrap=%none -fns=no -fsimple=0
-xia=strict expands to:
-xinterval=strict -ftrap=%none -fns=no -fsimple=0
On x86 platforms, -xarch=sse2 must be specified for
32-bit compilations. -xia is not available on Linux
platforms.
For more information, see the Fortran 95 Interval
Arithmetic Programming Reference.
-xinline=rl
Synonym for -inline=rl.
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your
program for analysis by the Thread Analyzer. For more
information on the Thread Analyzer, see tha(1) for
details.
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.
-xinterval[={widestneed|strict|no}]
(SPARC) Enable processing of interval arithmetic
extensions.
Interval arithmetic is an extension to the numerical
computation techniques in Fortran 95. For further
information, see the Fortran 95 documentation.
This flag controls the expression evaluation syntax
permitted.
-xinterval specified without a value defaults to
widestneed.
no
Interval arithmetic is 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.
-xipo[={1|0|2}]
Perform interprocedural optimizations.
Invoke interprocedural analysis pass to perform whole-
program optimizations. -xipo optimizes across all
object files in the link step, and is not limited to
just the source files on the compile command.
Analysis and optimization is limited to object files
compiled with -xipo.
-xipo=0 disables interprocedural analysis.
-xipo=1 enables inlining across source files.
-xipo=2 adds whole-program detection and analysis,
including memory allocation and memory layout
optimizations to improve cache performance.
The default is -xipo=0
If specified without a value, -xipo=1 is assumed.
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. Otherwise, the
assumptions made by the compiler about the usage of
these called routines could be incorrect.
See the Fortran 95 User's Guide for additional
information about when not to use -xipo.
When compiling and linking in separate steps, you must
specify -xipo in both steps to be effective.
Libraries, even if compiled with -xipo do not
participate in crossfile interprocedural analysis.
Also, .s assembly language source files do not
participate in the analysis.
The -xipo flag is ignored if compiling with -S.
Additional information about -xipo:
Requires at least optimization level -xO4
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 not compiled with this flag.
See also -xjobs.
-xipo_archive={none|readonly|writeback}
Allow crossfile optimization to include archive (.a)
libraries.
none There is no processing of archive files.
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=readonly or
-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.
-xipo_archive requires an argument.
-xivdep[=p]
Disable or set interpretation of IVDEP directives
The IVDEP directive tells a compiler to ignore some or
all loop-carried dependences on array references that
it finds in a loop for purposes of optimization. This
enables a compiler to perform various loop
optimizations such as microvectorization, distribution,
software pipelining, etc., which would not be otherwise
possible. It is used in cases where the user knows
either that the dependences do not matter or that they
never occur in practice.
The interpretation of !DIR IVDEP directives depend upon
the value of the -xivdep option.
The following values for p are interpreted as follows:
loop - ignore assumed loop-carried vector dependences
loop_any - ignore all loop-carried vector dependences
back - ignore assumed backward loop-carried vector
dependences
back_any - ignore all backward loop-carried vector
dependences
none - do not ignore any dependences (disables IVDEP
directives)
These interpretations are provided for compatibility
with other vendor's interpretations of the IVDEP
directive.
For details, see the Fortran User's Guide.
-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.
Currently, -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 processors. Using a value that is
many times the number of available 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
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named
functions.
%all - prohibit stack related optimizations for all the
code
%none - allow stack related optimizations for all the
code
If not specified on the command line, the compiler
assumes -xkeepframe=%none
If specified but without a value, the compiler assumes
-xkeepframe=%all
This option is accumulative and can appear on the
command line multiple times. For example,
-xkeepframe=%all -xkeepframe=no%func1 indicates that
the stack frame should be kept for all functions except
func1. Also, -xkeepframe overrides -xregs=frameptr.
For example, -xkeepframe=%all -xregs=frameptr indicates
that the stack should be kept for all functions, but
the optimizations for -xregs=frameptr would not be
done.
-xknown_lib=lib
Recognize calls to a known library.
With this flag 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 special knowledge of that library.
lib may be any one of the following key words, or a
comma-delimited list of a selection of them:
blas
blas1
blas2
blas3
intrinsics
-xknown_lib=[blas | blas1 | blas2 | blas3 ]
The compiler recognizes calls to the following BLAS
library routines and is free to optimize
appropriately for the Sun Performance Library
implementation.
BLAS1 routines recognized by -xknown_lib=blas1:
caxpy ccopy cdotc cdotu crotg
cscal csrot csscal cswap dasum
daxpy dcopy ddot drot
drotg drotm drotmg dscal dsdot
dswap dnrm2 dzasum dznrm2 icamax
idamax isamax izamax sasum saxpy
scasum scnrm2 scopy sdot sdsdot
snrm2 srot srotg srotm srotmg
sscal sswap zaxpy zcopy zdotc
zdotu zdrot zdscal
zrotg zscal zswap
BLAS2 routines recognized by -xknown_lib=blas2:
cgemv cgerc cgeru ctrmv ctrsv
dgemv dger dsymv dsyr dsyr2
dtrmv dtrsv sgemv sger
ssymv ssyr ssyr2 strmv strsv
zgemv zgerc zgeru ztrmv ztrsv
BLAS3 routines recognized by -xknown_lib=blas3:
cgemm csymm csyr2k csyrk ctrmm
ctrsm dgemm dsymm dsyr2k dsyrk
dtrmm dtrsm sgemm ssymm ssyr2k
ssyrk strmm strsm zgemm zsymm
zsyr2k zsyrk ztrmm ztrsm
You can select any combination of these. For example
-xknown_lib=blas2,blas3
selects just the BLAS2 and BLAS3 routines.
You can select all the BLAS routines by specifying
-xknown_lib=blas
which is equivalent to
-xknown_lib=blas1,blas2,blas3
The compiler will ignore user-supplied versions of
these library routines and use the BLAS routines in
the Sun Performance Library or inline the routines.
The -library=sunperf option is needed to link with
the Sun Performance Library.
-xknown_lib=intrinsics
Specifying intrinsics has the effect of ignoring any
explicit EXTERNAL declarations for Fortran 95
intrinsics, thereby ignoring any user-supplied
intrinsic routines.
For a list of functions recognized by the compiler
as intrinsics, see Chapters 2 and 3 of the Fortran
Library Reference manual.
-xl (Obsolete)
This (f77) option is no longer supported. For the
equivalent options in the current Fortran compiler,
use: -f77=%all,no%backslash -vax=$all,no%debug
-xld (Obsolete)
This (f77) option is no longer supported. For the
equivalent options in the current Fortran compiler,
use: -f77=%all,no%backslash -vax=$all,no%debug
-xlang=f77
(SPARC) Include the appropriate runtime libraries and
insure the proper runtime environment for legacy
Fortran 77.
Interactions:
The option -xlang=f77 implies linking with the
f77compat library, and is a shorthand way for linking
Fortran 95 object files with Fortran 77 object files.
Using -xlang=f77 insures the proper runtime
environment.
Warnings:
Do not use -xnolib with -xlang.
If you are mixing Fortran object files with C++, link
with the C++ compiler and specify -xlang=f95.
If you are mixing parallel Fortran objects with C++
objects, the link line must specify the -mt flag.
-xlibmil
Synonym for -libmil.
-xlibmopt
Use library of optimized math routines
Use a library of selected math routines optimized for
performance. This option usually generates faster
code. It might 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.
Default rounding mode, -fround=nearest, is assumed and
required when using this option.
-xlicinfo
(Obsolete) This option is silently ignored by the
compiler.
-xlic_lib=sunperf
(Obsolete) Use -library=sunperf to link with the Sun
Performance Library
-xlinkopt[=level]
(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 value level sets the level of
optimizations performed, and must be 0, 1, or 2.
The optimization levels are:
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.
2 Perform additional data flow analysis, including
dead-code elimination and address computation
simplification, at link time.
Specifying -xlinkopt without a level parameter implies
-xlinkopt=1.
These optimizations are performed at link time by
analyzing the object binary code. The object files are
not rewritten but the resulting executable code might
differ from the original object codes.
This option is most effective when used to compile the
whole program, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear
on both compile and link steps:
% f95 -c -xlinkopt a.f95 b.f95
% f95 -o myprog -xlinkopt=2 a.o b.o
Note that the level parameter is only used when the
compiler is linking. In the example above, the post-
optimization level used is 2 even though the object
binaries were compiled with an implied level of 1.
For -xlinkopt 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.
-xlinkopt 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 follows:
% f95 -o progt -xO5 -xprofile=collect:profdir
% progt
% f95 -o prog -xO5 -xprofile=use:prog
For details on using profile feedback, see -xprofile
Note that compiling with this option will increase link
time slightly. Object file sizes will also increase,
but the size of the executable remains the same.
Compiling with -xlinkopt and -g increases the size of
the executable by including debugging information.
-xloopinfo
Synonym for -loopinfo
-xmaxopt[=n]
Enable optimization pragma and set maximum optimization
level.
Limits the optimization level specified by a !$PRAGMA
SUN OPT=m directive to n. When a directive specifying
a level m greater than n on the -xmaxopt flag appears,
the compiler will use n.
The value n corresponds to the values 1 through 5 of
the -O optimization level flag. The value of n must be
greater or equal to the value of highest optimization
level specified by other options. So, for example:
f95 ... -O3 -xmaxopt=4
would be appropriate.
The flag -xmaxopt by itself defaults to -xmaxopt=5
-xmemalign[=ab]
(SPARC) Specify maximum assumed memory alignment and
behavior of misaligned data accesses.
For memory accesses where the alignment is determinable
at compile time, the compiler will generate the
appropriate load/store instruction sequence for that
alignment of data.
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 in these indeterminable situations. It also
specifies the error behavior to be followed at run-time
when a misaligned memory access does take place.
VALUES:
If a value is specified, it must consist of two parts:
a numerical alignment value, a, and an alphabetic
behavior flag, b.
Allowed values for alignment, a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Allowed values for behavior, b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f For all SPARC 64-bit platforms, raise signal
SIGBUS for alignments less than or equal to 4,
otherwise interpret access and continue
execution. For all other -xarch values, the f
flag is equivalent to i.
Defaults:
The first default, which applies when no -xmemalign
flag appears, is:
-xmemalign=8i for 32-bit SPARC platforms (-m32)
-xmemalign=8s on 64-bit SPARC platforms for C and
C++ (-m64)
-xmemalign=8f on 64-bit SPARC platforms for Fortran
(-m64)
The second default, which applies when -xmemalign
appears but without a value, is -xmemalign=1i for all
platforms
Note that -xmemalign itself does not force a particular
data alignment. See -dalign or -aligncommon.
You must also specify -xmemalign whenever you link to
an object file that was compiled with a value of b
either i or f.
-xmodel=[a]
(x86) Specify the data address model for shared objects
on Oracle Solaris x64 platforms.
The -xmodel option enables the compiler to create 64-
bit shared objects for the Oracle Solaris x64 platforms
and should only be specified for the compilation of
such objects.
This option is valid only when -m64 is also specified
on 64-bit enabled x64 processors.
a is one of the following:
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 2^31 - 2^24 - 1.
kernel
Generates code for the kernel model in which all
symbols are defined to be in the range from 2^64 -
2^31 to 2^64 - 2^24.
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.
Be aware that not all Linux system support the medium
model.
-xnolib
Synonym for -nolib.
-xnolibmil
Synonym for -nolibmil.
-xnolibmopt
Cancel -xlibmopt
Use with -fast to cancel linking with the optimized
math library.
-xO[n]
Synonym for -O[n].
-xopenmp[={parallel|noopt|none}]
Enable explicit parallelization with Fortran 95 OpenMP
version 3.1 directives.
The flag accepts the following suboption keywords:
parallel
Enables recognition of OpenMP pragmas. 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.
noopt
Enables recognition of OpenMP pragmas without
rasing the optimization level.
If you compile with an optimization level and
-xopenmp=noopt, it must be -xO3 or higher,
otherwise a compilation error is issued.
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.
none
Disables recognition of OpenMP pragmas, the
optimization level is not changed, and no OpenMP-
related preprocessor strings are defined. (This
is the default when -xopenmp is not specified.)
-xopenmp specified without a suboption keyword is
equivalent to -xopenmp=parallel. This default could
change in future releases. You can avoid warning
messages by explicitly specifying an optimization level
with -xopenmp.
Sub-options parallel, or noopt will define the _OPENMP
preprocessor macro to be the decimal value yyyymm where
yyyy and mm are the year and month designations of the
version of the OpenMP API that the implementation
supports. Refer to the Oracle Solaris Studio OpenMP
API User's Guide for the value of the _OPENMP macro for
a particular release.
Sub-options parallel and noopt will invoke -stackvar
automatically.
When debugging OpenMP programs with dbx, compile with
-g -xopenmp=noopt
to be able to breakpoint within parallel regions and
display the contents of variables.
Use the OMP_NUM_THREADS environment variable to specify
the number of threads to use when running an OpenMP
program. If OMP_NUM_THREADS is not set, the default
number of threads used is 2. To use more threads, set
OMP_NUM_THREADS to a higher value. Set OMP_NUM_THREADS
to 1 to run with just one thread. In general, set
OMP_NUM_THREADS to the available number of virtual
processors on the running system, which can be
determined by using the Oracle Solaris psrinfo(1)
command. See the OpenMP API User's Guide for more
information.
To enable nested parallelism, you must set the
OMP_NESTED environment variable to TRUE. Nested
parallelism is disabled by default. See the Oracle
Solaris Studio OpenMP API User's chapter on nested
parallelism for details.
When compiling and linking in separate steps, include
-xopenmp on the link step as well. This is especially
important when compiling dynamic (.so) libraries. The
same release of the compiler should be used to compile
libraries that contain OpenMP directives as the
programs that reference these libraries.
For bgest performance and functionality, make sure that
the latest patch of the OpenMP runtime library,
libmtsk.so, is installed on the running system.
The Fortran 95 OpenMP is described in the Oracle
Solaris Studio OpenMP API User's
-xpad
Synonym for -pad
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC:
8K 64K 512K 4M 32M 256M 2G 16G or default.
On x86:
4K 2M 4M 1G or default.
You must specify a valid page size for the Oracle
Solaris OS on the target platform. If you do not
specify a valid page size, the request is silently
ignored at run-time. The Oracle Solaris OS offers no
guarantee that the page size request will be honored.
You can use pmap(1) or pagesize(1) or meminfo(2) to
determine page size of the target platform.
If you specify -xpagesize=default, the flag is ignored.
-xpagesize without an argument is the equivalent to
-xpagesize=default.
This option is a macro for
-xpagesize_heap=n -xpagesize_stack=n
These two options accept the same arguments as
-xpagesize. You can set them both with the same value
by specifying -xpagesize=n 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 OS 9
command ppgsz(1) with the equivalent options before
running the program. See the Oracle Solaris OS man
pages for details.
-xpagesize_heap=n
Set the page size in memory for the heap.
n is the same as described for -xpagesize.
See -xpagesize for further details.
-xpagesize_stack=n
Set the page size in memory for the stack.
n is the same as described for -xpagesize.
See -xpagesize for further details.
-xpec[={yes|no}]
Generate a PEC (Portable Executable Code) binary.
This option puts the program intermediate
representations in the object file and the binary. This
binary may be used later for tuning and
troubleshooting.
A binary built with -xpec is usually 5 to 10 times
larger than if it is built without.
The default is -xpec=no. Without an argument, -xpec is
equivalent to -xpec=yes.
-xpentium
(x86) Same as -xtarget=pentium
-xpg Synonym for -pg.
-xpp={fpp|cpp}
Selects the source file preprocessor to be used with .F
.F95 .F03 files.
The default is fpp, which is appropriate for Fortran.
Previous versions of the compiler used cpp, the
standard C language preprocessor. To select cpp,
specify -xpp=cpp.
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those
architectures that support prefetch. Requires compiling
with an optimization level -xO3 or higher.
a must be one of the following values.
Value Meaning
auto Enable automatic generation of prefetch
instructions.
no%auto Disable automatic generation
explicit Enable explicit prefetch directives
no%explicit Disable explicit prefectch directives.
latx:factor (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.
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
might 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 might not
always be optimal. For memory-intensive
applications, especially applications
intended to run on large
multiprocessors, you might be able to
obtain better performance by increasing
the prefetch latency values. To increase
the values, use a factor that is greater
than 1 (one). 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 might be able to obtain
better performance by decreasing the
prefetch latency values. To decrease
the values, use a factor that is less
than one.
To use the latx:factor suboption, 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 Same as -xprefetch=auto,explicit. No
other suboptions may be specified.
no Same as -xprefetch=no%auto,no%explicit.
No other suboptions may be specified.
With -xprefetch, -xprefetch=auto, and -xprefetch=yes,
the compiler is free to insert prefetch instructions
into the code it generates. This can result in a
performance improvement on architectures that support
prefetch.
Defaults:
If -xprefetch is not specified,
-xprefetch=auto,explicit is assumed.
If only -xprefetch is specified,
-xprefetch=auto,explicit is assumed.
If automatic prefetching is enabled, such as with
-xprefetch or -xprefetch=yes, but a latency factor is
not specified, then latx:1.0 is assumed.
Interactions:
With -xprefetch=explicit, the compiler will recognize
the directives:
!$PRAGMA SUN_PREFETCH_READ_ONCE (address)
!$PRAGMA SUN_PREFETCH_READ_MANY (address)
!$PRAGMA SUN_PREFETCH_WRITE_ONCE (address)
!$PRAGMA SUN_PREFETCH_WRITE_MANY (address)
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 is enabled. That is, latx:factor is ignored
unless it is used with auto.
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 the latx:factor
suboption when the performance tests indicate there is
a clear benefit. The assumed prefetch latencies might
change from release to release. Therefore, retesting
the effect of the latency factor on performance
whenever switching to a different release is highly
recommended.
-xprefetch_auto_type=[no%]indirect_array_access
Generate indirect prefetches for a data arrays accessed
indirectly.
[no%]indirect_array_access
Does [not] generate 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.
If you do not specify a setting for
-xprefetch_auto_type, the compiler sets it to
-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.
-xprefetch_level=n
Control the degree of insertion of prefetch
instructions.
This option is effective only when compiling with
-xprefetch=auto, with optimization level 3 or greater
(-xO3), and on a platform that supports prefetch.
n may be 1, 2, or 3.
The default with -xprefetch=auto is level 2.
Prefetch level 2 finds additional opportunities for
prefetch instructions than level 1. Prefetch level 3
finds additional prefetch instructions than level 2.
Prefetch levels 2 and 3 may not be effective on older
SPARC and x86 platforms.
-xprofile=p
Collects data for a profile or use a profile to
optimize.
p must be collect[:profdir], use[:profdir], or
tcov[:profdir]
This option causes execution frequency data to be
collected and saved during execution, then the data can
be used in subsequent runs to improve performance.
Profile collection is safe for multithreaded
applications. That is, profiling a program that does
its own multitasking ( -mt ) produces accurate results.
This option is only valid when you specify -xO2 or
greater level of optimization.
If compilation and linking are performed in separate
steps, the same -xprofile option must appear on the
compile as well as the link step.
collect[:profdir]
Collects and saves execution frequency for later
use by the optimizer with -xprofile=use. The
compiler generates code to measure statement
execution-frequency.
-xMerge -ztext -xprofile=collect should not be
used together. While -xMerge forces statically
initialized data into read-only storage, -ztext
prohibits position-dependent symbol relocations in
read-only storage, and -xprofile=collect generates
statically initialized, position-dependent symbol
relocations in writable storage.
The profile directory name profdir, if specified,
is the pathname of the directory where profile
data are to be stored when a program or shared
library containing the profiled object code is
executed. If the pathname is not absolute, it is
interpreted relative to the current working
directory when the program is compiled with the
option -xprofile=use:profdir.
If no profile directory name is specified with
-xprofile=collect:prof_dir or
-xprofile=tcov:prof_dir, profile data are stored
at run time in a directory named program.profile
where program is the basename of the profiled
process's main program. In this case, the
environment variables SUN_PROFDATA and
SUN_PROFDATA_DIR can be used to control where the
profile data are stored at run time. If set, the
profile data are written to the directory given by
$SUN_PROFDATA_DIR/$SUN_PROFDATA.
If a profile directory name is specified at
compilation time, SUN_PROFDATA_DIR and
SUN_PROFDATA have no effect at run time. 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.
If these environment variables are not set, the
profile data is written to the directory
profdir.profile in the current directory, where
profdir is the name of the executable or the name
specified in the -xprofile=collect:profdir flag.
-xprofile does not append .profile to profdir if
profdir already ends in .profile. If you run the
program several times, the execution frequency
data accumulates in the profdir.profile directory;
that is, output from prior executions is not lost.
Example[1]: to collect and use profile data in
the directory myprof.profile located in the same
directory where the program is built:
f95 -xprofile=collect:myprof.profile -xO5 prog.f95 -o prog
./prog
f95 -xprofile=use:myprof.profile -xO5 prog.f95 -o prog
Example[2]: to collect profile data in the
directory /bench/myprof.profile and later use the
collected profile data in a feedback compilation
at optimization level -xO5:
f95 -xprofile=collect:/bench/myprof.profile -xO5 prog.f95 -o prog
...run prog from multiple locations...
f95 -xprofile=use:/bench/myprof.profile -xO5 prog.f95 -o prog
If you are compiling and linking in separate
steps, make sure that any object files compiled
with -xprofile=collect are also linked with
-xprofile=collect.
See also the ENVIRONMENT section of this man page
below for descriptions of environment variables
that control asynchronous profile collections.
use[:profdir]
Uses execution frequency data collected from code
compiled with -xprofile=collect[:profdir] or
-xprofile=tcov[:profdir] to optimize for the work
performed when the profiled code was executed.
profdir is the pathname of a directory containing
profile data collected by running a program that
was compiled with -xprofile=collect[:profdir] or
-xprofile=tcov[:profdir].
To generate data that can be used by both tcov and
-xprofile=use[:profdir], the same profile
directory must be specified at compilation time,
using the option -xprofile=tcov[:profdir]. To
minimize confusion, specify profdir as an absolute
pathname.
The profdir is optional. If profdir is not
specified, the name of the executible binary is
used. a.out is used if -o is not specified. The
compiler looks for profdir.profile/feedback, or
a.out.profile/feedback without profdir specified.
For example:
f95 -xprofile=collect -o myexe prog.f95
f95 -xprofile=use:myexe -xO5 -o myexe prog.f95
The program is optimized by using the execution
frequency data previously generated and saved in
the feedback files written by a previous execution
of the program compiled with -xprofile=collect.
Except for the -xprofile option, the source files
and other compiler options must be exactly the
same as those used for the compilation that
created the compiled program which in turn
generated the feedback file. The same version of
the compiler must be used for both the collect
build and the use build as well.
If compiled with -xprofile=collect:profdir, the
same profile directory name profdir must be used
in the optimizing compilation:
-xprofile=use:profdir.
See also -xprofile_ircache for speeding up
compilation between collect and use phases.
tcov[:profdir]
Instrument object files for basic block coverage
analysis using tcov(1).
If the optional :profdir argument is specified,
the compiler will create a profile directory at
the specified location. The data stored in the
profile directory can be used either by tcov(1) or
by the compiler with -xprofile=use:profdir .
If the optional :profdir argument is omitted, a
profile directory will be created when the
profiled program is executed. The data stored in
the profile directory can only be used by tcov(1).
The location of the profile directory can be
controlled using environment variables
SUN_PROFDATA and SUN_PROFDATA_DIR. See ENVIRONMENT
below.
If the location specified by :profdir is not an
absolute pathname, it is interpreted relative to
the current working directory when the program is
compiled.
If :profdir is specified for any object file, the
same location must be specified for all object
files in the same program. The directory whose
location is specified by :profdir must be
accessible from all machines where the profiled
program is to be executed. The profile directory
should not be deleted until its contents are no
longer needed, because data stored there by the
compiler cannot be restored except by
recompilation.
Example 1: if object files for one or more
programs are compiled with
-xprofile=tcov:/test/profdata, a directory named
/test/profdata.profile will be created by the
compiler and used to store data describing the
profiled object files. The same directory will
also be used at execution time to store execution
data associated with the profiled object files.
Example 2: if a program named "myprog" is compiled
with -xprofile=tcov and executed in the directory
/home/joe, the directory /home/joe/myprog.profile
will be created at run time and used to store
runtime profile data.
-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.
A typical sequence of commands might be:
f95 -xO5 -xprofile=collect -xprofile_ircache t1.f95 t2.f95
a.out // run collects feedback data
f95 -xO5 -xprofile=use -xprofile_ircache t1.f95 t2.f95
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.
-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:
o You are compiling with -xprofile=use
into a directory that is not the directory used when
previously compiling with -xprofile=collect.
o Your object files share a common base name in the profile
but are distinguished from each other by their
location in different directories.
The collect-prefix is the prefix of the UNIX path name
of a directory tree in which object files were compiled
using -xprofile=collect.
The use-prefix is the prefix of the UNIX path name 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
path name until either a matching use-prefix is
identified or the last specified use-prefix is found
not to match the object file path name.
-xrecursive
Allow routines defined without RECURSIVE attribute to
call themselves recursively.
Normally, only subprograms defined with the RECURSIVE
attribute can call themselves recursively.
Compiling with -xrecursive enables subprograms to call
themselves recursively even if they are not defined
with the attribute RECURSIVE. But, unlike the
RECURSIVE attribute, this flag does not cause local
variables to be allocated on the stack by default. For
each recursive invocation of the subprogram to have
separate values for local variables, compile with
-stackvar to put local variables on the stack.
Compiling routines with -xrecursive can cause
performance degradations.
-xreduction
Synonym for -reduction
-xregs=r[,r...]
Specify the usage of registers for the generated code.
r is a comma-separated list of one or more of the
following suboptions: appl, float, frameptr.
Prefixing a suboption with no% disables that suboption.
Example: -xregs=appl,no%float
Note that -xregs suboptions are restricted to specific
hardware platforms.
appl (SPARC)
Allow the compiler to generate code using the
application registers as scratch registers.
The application registers are:
g2, g3, g4 (on 32-bit platforms)
g2, g3 (on 64-bit platforms)
It is strongly recommended that all system
software and libraries be compiled using
-xregs=no%appl. System software (including
shared libraries) must preserve these
registers' values for the application. Their
use is intended to be controlled by the
compilation system and must be consistent
throughout the application.
In the SPARC ABI, these registers are
described as application registers. Using
these registers can increase performance
because fewer load and store instructions are
needed. However, such use can conflict with
some old library programs written in assembly
code.
For more information on SPARC instruction
sets, see -xarch.
float (SPARC)
Allow the compiler to generate code by using
the floating-point registers as scratch
registers for integer values. Use of
floating-point values may use these registers
regardless of this option. To generate binary
code free of all references to floating point
registers, use -xregs=no%float and make sure
your source code does not in any way use
floating point types.
frameptr (x86)
Allow the compiler to use the frame-pointer
register (%ebp on IA32, %rbp on x86 64-bit
platforms) as a general-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr
unless exceptions are also disabled with
-features=no%except. Note also that
-xregs=frameptr is part of -fast, but is
ignored by the C++ compiler unless
-features=no%except is also specified.
With -xregs=frameptr the compiler is free to
use the frame-pointer register to improve
program performance. However, some features of
the debugger and performance measurement tools
may be limited. Stack tracing, debuggers, and
performance analyzers cannot report on
functions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will
fail trying to find cleanup handlers.
Mixed C, Fortran, and C++ code should not be
compiled with -xregs=frameptr if a C++
function, called directly or indirectly from a
C or Fortran function, can throw an exception.
If compiling such mixed source code with
-fast, add -xregs=no%frameptr after the -fast
option on the command line.
With more available registers on 64-bit
platforms, compiling with -xregs=frameptr has
a better chance of improving 32-bit code
performance than 64-bit code.
Note: -xregs=frameptr is ignored and a
warning is issued by the compiler if you also
specify -xpg. Also, -xkeepframe overrides -
xregs=frameptr.
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr.
-xregs=frameptr is included in the expansion of -fast
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 are aware of
these register assignments.
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.
-xs Allow debugging by dbx without object files.
This option causes all the debug information to be
copied into the executable. There is little impact on
dbx performance or the run-time performance of the
program, but it does take more disk space.
With -xs, if you move executables to another directory,
then you can use dbx and ignore the object (.o) files.
Use this option in case you cannot retain the .o object
files.
-xsafe=mem
(SPARC) Allow the compiler to assume that no memory
protection violations occur.
This option allows the compiler to use the non-faulting
load instruction in the SPARC V9 architecture.
Warnings:
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
for programs that explicitly depend on memory-based
traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with
optimization level -xO5 and one of the following -xarch
values: sparc, sparcvis, sparcvis2, sparcvis3, for both
-m32, and -m64.
-xspace
Do not increase code size
Do no optimizations that increase the code size.
Example: Do not unroll loops.
-xtarget=t
Specify the target system 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 systems. The only
meaning of -xtarget is in its expansion.
The -xtarget values are:
native: Get the best performance on the host system
(32-bit architecture). Expands to:
-m32 -xarch=native -xchip=native -xcache=native
native64: This is obsolete. Use -xtarget=native -m64
instead.
generic: Get the best performance for most 32-bit
platforms This is the default and expands to:
-m32 -xarch=generic -xchip=generic -xcache=generic
generic64: This is obsolete. Use -xtarget=generic -m64
instead.
platform-name: Get the best performance for the
specified platform.
Valid SPARC platform names are shown below.
Commonly used platform names:
ultra, ultra2, ultra2i, ultra1/140, ultra1/170,
ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300,
ultra2/2170, ultra2/2200, ultra2/2300, ultra2e,
ultra2i, ultra3, ultra3cu, ultra3i, ultra4,
ultra4plus, ultraT1 ultraT2, ultraT2plus, T3, T4,
sparc64vi, sparc64vii, sparc64viiplus.
Compiling for a 64-bit Oracle Solaris OS on UltraSPARC
V9 platforms is indicated by the -m64 flag. If -xtarget
is specified, the -m64 option must also appear, as in:
-xtarget=ultra2 ... -m64
otherwise a 32-bit memory model will be used.
On x86 systems, the valid platform names are: generic,
native, pentium, pentium_pro, pentium3, pentium4,
woodcrest, penryn, nehalem, sandybridge, westmere,
barcelona, and opteron.
Compiling for 64-bit Oracle Solaris OS on 64-bit x86 AMD
Opteron platforms is indicated by the -m64 flag, as in:.
-xtarget=opteron -m64
otherwise the compilation will revert to 32-bit x86.
See the Fortran User's Guide for the -xtarget expansions
showing the actual -xarch -xchip -xarch values used for
each platform name.
This option is a macro. Each specific value for -xtarget
expands into a specific set of values for the -xarch,
-xchip, and -xcache options. For example:
-xtarget=ultra4 is equivalent to:
-xarch=sparcvis -xcache=64/32/4:8192/128/2 -xchip=ultra4
To determine the expansion of any -xtarget platform name
on a running system, execute the command
f95 -xtarget=platform_name -dryrun |& grep ###
For example:
f95 -dryrun -xtarget=ultra4 |& grep ###
### command line files and options (expanded):
### -dryrun -xarch=sparcvis -xcache=64/32/4:8192/128/2 -xchip=ultra4
Note that -xtarget for a specific host platform might
not expand to the same -xarch, -xchip, or -xcache
settings as -xtarget=native when compiling on that
platform.
-xtime
Synonym for -time.
-xtypemap=spec
Specify default data mappings.
This option provides a flexible way to specify the byte
sizes for default data types.
The syntax of the string spec is:
type:bits,type:bits,...
The allowable data types are REAL, DOUBLE, INTEGER. The
data sizes accepted are 16, 32, 64, and 128.
This option applies to all variables declared without
explicit byte sizes, as in REAL XYZ.
The allowable combinations are:
real:32
real:64
double:64
double:128
integer:16
integer:32
integer:64
A useful mapping is:
-xtypemap=real:64,double:64,integer:64
which maps REAL and DOUBLE to 8 bytes, but does not
promote DOUBLE PRECISION to QUAD PRECISION.
Note also that INTEGER and LOGICAL are treated the same,
and COMPLEX is mapped as two REAL data elements. Also,
DOUBLE COMPLEX will be treated the way DOUBLE is mapped.
For more information, see the Fortran User's Guide
-xunroll=n
Synonym for -unroll=n
-xvector[=a]
Enables automatic generation of calls to the vector
library and/or the generation of the SIMD (Single
Instruction Multiple Data) instructions on x86
processors that support SIMD. You must use default
rounding mode by specifying -fround=nearest when you use
this option.
The -xvector option requires optimization level -xO3 or
greater. Compilation will not proceed if the
optimization level is unspecified or lower than -xO3,
and a message is issued.
a is the equivalent of the following:
[no%]lib
(SOLARIS Only) 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. Use no%lib to disable this option.
[no%]simd
(x86 Only) Directs the compiler to use the native
x86 SSE SIMD instructions to improve performance of
certain loops. Streaming extensions are used on
x86 by default at optimization level 3 and above
where beneficial. Use no%simd to disable this
option.
The compiler will use SIMD only if streaming
extensions exist in the target architecture; that
is, if target ISA is at least SSE2. For example,
you can specify -xtarget=woodcrest,
-xarch=generic64, -xarch=sse2, -xarch=sse3, or
-fast on a modern platform to use it. If the target
ISA has no streaming extensions, the suboption will
have no effect.
%none
Disable this option entirely.
yes This option is deprecated, specify -xvector=lib
instead.
no This option is deprecated, specify -xvector=%none
instead.
The default is -xvector=simd on x86 and -xvector=%none
on SPARC platforms. If you specify -xvector without a
suboption, the compiler assumes -xvector=simd,lib on x86
Oracle Solaris, -xvector=lib on SPARC Oracle Solaris,
and -xvector=simd on Linux platforms.
This option overrides previous instances so
-xvector=%none undoes a previously specified
-xvector=lib.
The compiler includes the libmvec libraries in the load
step. If you specify -xvector at compile time, you must
also specify it at link time.
-xvpara
Synonym for -vpara
-ztext
Make no library with relocations
Do not make the library if relocations remain. The
general purpose of -ztext is to verify that the
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 writeable.
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.
-ztext -xprofile=collect should not be used together.
-ztext prohibits position-dependent symbol relocations
in read-only storage, and -xprofile=collect generates
statically initialized, position-dependent symbol
relocations in writable storage.
Other arguments are taken to be either linker option
arguments, or names of f95-compatible object programs,
typically produced by an earlier run, or libraries of
routines that are f95-compatible. These programs, together
with the results of any compilations specified, are linked
in the order given to produce an executable program in the
file specified by the -o option, or in a file named a.out if
the -o option is not specified.
FILE SUFFIXES
Files with the following suffixes may appear on the compiler
command line. The suffix usually identifies the type of the
file and determines how the compiler processes it.
.f .for
Fixed format Fortran source files.
.f90 .f95 .f03
Free format Fortran 90, Fortran 95, or Fortran 2003
source files.
.F Fixed format Fortran source containing preprocessor
directives. These files are preprocessed by fpp(1)
before they are compiled. (See also the -xpp= option.)
.F90 .F95 .F03
Free format Fortran 95 source containing preprocessor
directives. These files are preprocessed fpp(1) before
they are compiled. (See also the -xpp= option.)
.s Assembler source files.
.il Inline assembler expansion code template files. Used
by the compiler to expand calls to selected routines
into inline code. See the inline(1) man page and -
inline option flag for more information on inline
template files.
.o Object files to be passed to the linker.
.so Shared object files or libraries to be passed to the
linker.
.a Library files passed to the linker, or searched for
MODULE subprograms (see the -M option flag.)
.mod Files containing precompiled MODULE program units.
These are generated by the compiler. See the -M option
flag.
DIRECTIVES
General Directives: f95 allows general compiler directive
lines starting with C$PRAGMA, (in fixed-format only), or
!$PRAGMA, and either uppercase or lowercase is allowed.
!$PRAGMA C(list_of_subprogram_names)
!$PRAGMA SUN UNROLL n
!$PRAGMA WEAK function_name
!$PRAGMA SUN OPT=n
!$PRAGMA PIPELOOP=n
!$PRAGMA SUN_PREFETCH_READ_ONCE (name)
!$PRAGMA SUN_PREFETCH_READ_MANY (name)
!$PRAGMA SUN_PREFETCH_WRITE_ONCE (name)
!$PRAGMA SUN_PREFETCH_WRITE_MANY (name)
!$PRAGMA IGNORE_TKR list
!$PRAGMA ASSUME (expression [, probability])
Parallelization Directives: f95 recognizes the OpenMP API
parallelization directives. OpenMP is the recommended model
for explicit parallelization for all the Oracle Solaris
Studio compilers.
In this release, the f95 compiler accepts Version 2.5 of the
OpenMP Fortran 95 API. These have the sentinel !OMP.
For detailed information on the Oracle Solaris Studio OpenMP
implementation, see the OpenMP API User's Guide.
ENVIRONMENT
The paths shown below assume the root of the Oracle Solaris
Studio software installation is indicated by <install-
directory>. Contact your system administrator to determine
the actual path.
PATH
To use f95, add the following to the start of the search
path:
<install-directory>/bin/
MANPATH
To access the f95 man pages, add the following to the
MANPATH environment variable:
<install-directory>/man/
MODDIR
Specifies the path to the directory where the compiler will
write .mod module files. See also -moddir, which takes
precedence over the setting of the MODDIR environment
variable.
LD_LIBRARY_PATH
Generally, you need not set up LD_LIBRARY_PATH. If you do
need to do so, then maybe there is some discrepancy in the
installation, or some executable has been built incorrectly.
Set the LD_LIBRARY_PATH, environment variable to:
<install-directory>/lib/
LD_LIBRARY_PATH_64
Like the LD_LIBRARY_PATH environment variable,
LD_LIBRARY_PATH_64 sets the path for searching for 64-bit
libraries.
When running in a 64-bit enabled Oracle Solaris OS and
linking in 32-bit mode, LD_LIBRARY_PATH_64 is ignored. If
only LD_LIBRARY_PATH is defined, it us used for both 32-bit
and 64-bit linking. If both LD_LIBRARY_PATH and
LD_LIBRARY_PATH_64 are defined, the 32-bit linking will be
done using LD_LIBRARY_PATH and the 64-bit linking using
LD_LIBRARY_PATH_64.
See Linker and Libraries Guide for more information on these
environment variables.
LD_RUN_PATH
If you use LD_RUN_PATH, note that for f95, LD_RUN_PATH is
not identical with -R. (For ld.so, they are identical.)
See -R, in the Fortran User's Guide, for details.
STACKSIZE
You can set the stack size to be used by each slave thread
in a multithreaded program by giving the STACKSIZE
environment variable a value (in Kilobytes):
% setenv STACKSIZE 8192
sets the stack size for each slave thread to 8 Mb.
The default thread stack size on 32-bit systems is 4
megabytes. On 64-bit systems it is 8 megabytes.
The STACKSIZE environment variable also accepts numerical
values with a suffix of either B, K, M, or G for bytes,
kilobytes, megabytes, or gigabytes respectively. The
default is kilobytes. (Note that the term "kilobyte"
actually means 1024 bytes.)
See the Fortran Programming Guide chapter on Parallelizaion
for details.
SUNW_MP_WARN
Controls warning messages issued by the OpenMP runtime
library. If set TRUE the library issues warning messages to
stderr. Set FALSE disables warnings. The default is FALSE.
SUNW_MP_THR_IDLE
Controls end-of-task status of each helper thread and can be
set to SPIN, or SLEEP ns. Default is SLEEP. See the OpenMP
API User's Guide for details on these and other OpenMP
environment variables .
OMP_NUM_THREADS
Sets the number of threads to use during application
execution. See the OpenMP API User's Guide for details on
these and other OpenMP environment variables .
TMPDIR
The compiler normally creates temporary files in the
directory /tmp. You may specify another directory by setting
the environment variable TMPDIR to your chosen directory.
(If TMPDIR isn't a valid directory, the compiler will use
/tmp). The -temp option has precedence over the TMPDIR
environment variable.
SUN_PROFDATA=profdir
If set, store profile data collected from a program compiled
with -xprofile=collect in a directory named profdir in the
current working directory at the time that the program is
executed. If the optional argument :profdir was specified
in -xprofile=collect[:profdir] at compilation time,
SUN_PROFDATA as no effect.
SUN_PROFDATA_DIR=dirname
If set, store profile data collected from a program compiled
with -xprofile=collect in a directory whose UNIX dirname is
dirname. If dirname is not absolute, it is interpreted
relative to the current working directory at the time that
the program is executed. If the optional argument :profdir
was specified in -xprofile=collect[:profdir] at compilation
time, SUN_PROFDATA_DIR has no effect.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchronous profile
collection. In asynchronous profile collection, profile
data are collected from a running process at regular
intervals whose duration is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the
environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64
is set to /usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-safe, mmap
based memory allocator, such as libumem(3) with mmap-based
allocation specified by setting UMEM_OPTIONS to
backend=mmap.
Example: to enable asynchronous profile collection from a 64
bit process at 1 minute intervals,specify the following
environment variables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
SUN_PROFDATA_ASYNC_VERBOSE=verbose
If set nonzero, enables verbose messages from asynchronous
collector to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no
effect unless asynchronous profile collection is enabled.
SUN_PROFDATA_REPLACE={objfile,program,all}
SUN_PROFDATA_REPLACE indicates the scope of profile data to
be reset when a changed version of an object file is
detected at runtime. Use SUN_PROFDATA_REPLACE to ensure
that profile data are consistent with the profiled program
within the specified unit of program scope.
The values of SUN_PROFDATA_REPLACE and their meanings
are as follows:
objfile
reset profile data of changed object file
program
reset profile data of all object files in program
containing changed object file
all reset entire contents of profile directory if any
object file has changed
The default setting of SUN_PROFDATA_REPLACE is
SUN_PROFDATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh)
$ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a changed
object file is executed, all object files in the
program will have their profile data reset. Relevant
options include -xOn and -xipo=n.
FILES
See the section FILE SUFFIXES above for files identified by
their name suffix that may appear on the compiler command
line.
In addition, the compiler uses the following files:
/usr/lib/libc.so
Standard C system library
/usr/lib/libm.so
Standard system math library
/tmp/*
Compiler temporary files
mon.out
File produced for analysis by prof(1)
gmon.out
File produced for analysis by gprof(1)
The following reside in the Oracle Solaris Studio
installation directory, as indicated by <install-directory>.
<install-directory>/bin/fpp
Fortran preprocessor
<install-directory>/bin/cpp
C preprocessor
<install-directory>/prod/include/f95/
Path searched for f95 INCLUDE statement
<install-directory>/prod/include/f95/floatingpoint.h
f95 IEEE arithmetic type definitions
The following libraries may exist in both .so and .a
versions: Note: Mixing static and shared Fortran runtime
libraries should be avoided; always link with the latest
shared Fortran libraries.
libfsu
f95 support intrinsics
libfui
f95 - UNIX interface
libfio
Fortran 95 I/O
libf*ai
Fortran 95 array intrinsics libraries
libifai
Fortran 95 interval array intrinsics library
libf77compat
f77 Fortran 77 compatibility library
libsunmath
Oracle Solaris Studio math lib
libsunimath
Oracle Solaris Studio interval math lib
xprof_fini.o
Initialization and finalization handlers for programs
compiled with -xprofile=collect
NOTES
For Solaris release 10, new shared libraries libxprof.so.1,
libxprof_audit.so.1, and libtdf.so.1 must be installed in
order to use the -xprofile option. These libraries are pre-
installed on the latest Oracle Solaris releases.
SEE ALSO
Complete Oracle Solaris Studio documentation for this
release is available on the Oracle Technical Network
website: http://www.oracle.com/technetwork/server-
storage/solarisstudio/documentation/index.html
Consult the following man pages for additional information:
asa(1), cc(1), dbx(1), fpp(1), fpr(1), fsplit(1),
gprof(1), ld(1), perror(3f), prof(1), tcov(1)
Consult the following manuals for detailed information:
Fortran User's Guide
Fortran Programming Guide
OpenMP API User's Guide
Numerical Computation Guide
Studio Performance Analyzer
Fortran Library Reference
Oracle Solaris OS Linker and Libraries Guide
Debugging a Program With dbx
Sun Performance Library User's Guide: This Oracle Solaris
Studio release includes the Sun Performance Library
containing subroutines and functions for operations in
computational linear algebra and Fourier transforms.
You can find much more information on the Oracle Solaris
Studio web site:
http://www.oracle.com/technetwork/server-
storage/solarisstudio
DIAGNOSTICS
The diagnostics produced by f95 itself are intended to be
self-explanatory. Occasional messages can be produced by the
linker.