f95(1)f95(1)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
.i or .c 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 95
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 file.f95
% progt
% f95-o prog -xO5 -xprofile=use:prog -profdir -xlinkopt file.f95
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 Guide
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 Guide.
-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 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.
December 2011 f95(1)