f95(1)f95(1)NAME
f95, f90 - Fortran 95 compiler
SYNOPSIS
May be invoked by either f95 or f90 commands; they are equivalent.
f95 [ -a ] [ -aligncommon[=a] ] [ -ansi ] [ -arg=local ]
[ -autopar ] [ -Bx ] [ -C ] [ -c ] [ -cg89 ] [ -cg92 ]
[ -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] ] [ -KPIC ] [ -Kpic ]
[ -Lpath ] [ -lx ] [ -libmil ] [ -loopinfo ] [ -Mpath ]
[ -m32|-m64 ] [ -moddir=path ] [ -mp=x ] [ -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 ] [ -U ] [ -Uname ] [ -u ]
[ -unroll=n ] [ -use=list ] [ -V ] [ -v ] [ -vax=v ]
[ -vpara ] [ -w[n] ] [ -Xlist[z] ] [ -xa ]
[ -xaddr32[={no|yes}] ] [ -xalias[=a[,a]...] ]
[ -xannotate[={yes|no}] ] [ -xarch=a ]
[ -xassume_control[=a[,a]...] ]
[ -xautopar ] [ -xbinopt={prepare|off} ]
[ -xcache=c ] [ -xcg89 ] [ -xcg92 ]
[ -xcheck=v ] [ -xchip=c ] [ -xcode=v ]
[ -xcommonchk[={no|yes}] ] [ -xcrossfile=n ]
[ -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 ] [ -xjobs=n ] [ -xknown_lib=lib ]
[ -xlang=f77 ] [ -xlibmil ] [ -xlibmopt ] [ -xlicinfo ]
[ -xlic_lib=sunperf ] [ -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
Sun Studio 12 Update 1 Fortran 95 compiler, version 8.3
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.0. It
also accepts many FORTRAN 77 (f77) language extensions under the -f77
compatibility option, and VAX VMS Fortran extensions (-vax).
Version 8.3 of the Fortran 95 compiler f95 is released as a component
of Sun Studio 12 Update 1, and is available for the Solaris[tm]
Operating System (Solaris OS) versions 9 and 10, on SPARC(R) and x86
platforms, on OpenSolaris x86 platforms, and on Linux x86 platforms.
For the latest important information on platforms, environments, new
features, limitations, problems, workarounds, and software corrections,
see the documentation on the Sun Studio web portal at
http://developers.sun.com/sunstudio/.
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. These manuals can be
accessed from the documentation pages on the Sun Studio portal
http://developers.sun.com/sunstudio/
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 Sun Studio documentation appears at the end of this
man page.
An index to all the installed Sun Studio documentation, including links
to documentation on the Sun Studio portal, can be found on the Sun
Studio portal at
http://developers.sun.com/sunstudio
Additional information, including technical articles and latest news
about patches and workarounds, can be found on the developer resources
portal at http://developers.sun.com/sunstudio/
COMPILING FOR 64-BIT PLATFORMS:
The way to specify compilation of a 32-bit or 64-bit binary has changed
in this release. The -xarch option no longer carries an implicit memory
model, 32-bit ILP32 or 64-bit LP64, with each definition, and is now
used only to specify the instruction set of the target processor.
Use the new -m32 and -m64 options to specify the memory model of the
target compilation.
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 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 UltraSPARC(R) or x86 processors under Solaris OS or Linux OS
running a 64-bit kernel. Compilation, linking, and execution of 64-bit
objects can only take place in a 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
Solaris platforms.
The legacy Sun-style and Cray-style parallelization directives are not
available on x86. Use OpenMP instead. See the OpenMP API User's Guide
for information on converting legacy parallelization directives to
OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or sse3 must be
run only on platforms that provide these extensions and features.
OS releases starting with Solaris 9 4/04 are SSE/SSE2- enabled on
Pentium 4-compatible platforms. Earlier versions of Solaris OS are not
SSE/SSE2-enabled. If an instruction set selected by -xarch is not
enabled in the running Solaris OS, the compiler will not be able to
generate or link code for that instruction set.
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 Solaris and Linux because the
intrinsic math libraries (for example, sin(x)) are not the same.
Binary Compatibility Verification
Starting with Sun Studio 11 and the Solaris 10 OS, program binaries
compiled and built using these specialized -xarch hardware flags are
verified that they are being run on the appropriate platform.
On systems prior to Solaris 10, no verification is done and it is the
user's responsibility to ensure objects built using these flags are
deployed on suitable hardware.
Running programs compiled with these -xarch options on platforms that
are not enabled with the appropriate features or instruction set
extensions could result in segmentation faults or incorrect results
occurring without any explicit warning messages.
This warning extends also to programs that employ .il inline assembly
language functions or __asm() assembler code that utilize SSE, SSE2,
SSE2a, and SSE3 instructions and extensions.
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-a (Obsolete) Profile by basic block for tcov
Count how often each basic block is executed. Run tcov(1) on
the source file to generate statistics about the program.
This is the old style of basic block profiling for tcov. Use
instead -xprofile=tcov.
-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.
Do not use -aligncommon=1 with -xmemalign as these declarations
will conflict and could cause a segmentation fault on some
platforms and configurations.
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: To run a parallelized program in a
multithreaded environment, you must set the OMP_NUM_THREADS
environment variable prior to execution. This variable tells the
runtime system the maximum number of threads the program can
create. The default is 1. In general, set OMP_NUM_THREADS to
the available number of virtual processors on the running
system, which can be determined by using the Solaris psrinfo(1)
command.
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 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 only, do not make executable file.
Compile and produce a .o file for each source file but suppress
linking by the loader. You can name a single object file
explicitly using the -o option.
-cg89 (Obsolete, SPARC) Generate code for generic SPARC architecture
This option is a macro for:
-xarch=v7 -xchip=old -xcache=64/32/1
and is equivalent to: -xtarget=ss2 This option should not be
used. Current Solaris operating systems no longer support SPARC
V7 architecture. Compiling with this option will generate code
that will run slower on current SPARC platforms. This feature
might not be supported in later versions of the compiler.
-cg92 (Obsolete, SPARC) Generate code for SPARC V8 architecture
This option is a macro for:
-xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1.
and is equivalent to: -xtarget=ss1000
This feature might not be supported in later versions of the
compiler.
-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, __sparcv9, __unix, __sun, __i386, __x86_64, __amd64,
__SVR4, __SunOS_5_6, __SunOS_5_7, __SunOS_5_8, __SunOS_5_9,
__SunOS_5_10
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 SPARC 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 dependence
analysis.
-depend=no disables DO loop data dependence analysis, and is the
default.
On SPARC, -xdepend is turned on for all optimization levels -xO3
and above, and is off for lower opt levels. Also, an explicit
setting of -xdepend overrides any implicit setting.
On x86, if optimization is not at -xO3 or higher, the compiler
raises the optimization to -xO3 and issues a warning.
-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 Solaris OS
platforms and 32-bit Solaris x86 platforms and all 32-bit
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
SPARC environments with -m64). The default alignment of data in
COMMON blocks is on 4-byte boundaries.
-f is equivalent to -aligncommon=16.
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=ultra ...
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.
(Solaris only)
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. (Solaris only)
o -nofstore cancels forcing expressions to have the precision of
the result. (x86)
o -xregs=frameptr allows the compiler to use the frame-pointer
register as an unallocated callee-saves register. Specify
-xregs=no%frameptr after -fast and the frame pointer register
will not be used as a general purpose register. (x86)
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.
-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.
To be effective this option must be used when compiling the main
program.
-G Build a dynamic shared library
Direct the linker to make a shared dynamic library. Without -G
the linker builds an executable file. With -G it builds a
dynamic library (but no executable). Use -o with -G to specify
the name of the file to be written.
For more information about dynamic libraries and how to create
them, see the Fortran Programming Guide.
-g Compile for debugging and performance analysis.
Produce additional symbol table information for debugging with
dbx(1) or the Sun Studio Debugger, and for analysis with the Sun
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 Sun 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 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. No 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 -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 or -xcrossfile are 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
-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.
-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.
A space between the -M and the path is allowed. For example, -M
/home/siri/PK15/Modules
On Solaris, if the path identifies a regular file that is not an
archive or a module file, the compiler passes the option to the
linker, ld, which will treat it as a linker mapfile. This
feature is provided as a convenience similar to the C and C++
compilers.
-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 Use multithread safe libraries
If you are doing your own multithread coding and not using
-autopar, then you must use the -mt option in the compile and
link steps. The parallelization options use -mt automatically.
On a single-processor system, the generated code usually runs
more slowly with this option.
-m32 | -m64
Specify memory model for compiled binary object.
Use -m32 to create 32-bit executables and shared libraries. Use
-m64 to create 64-bit executables and shared libraries.
The ILP32 memory model (32-bit int, long, pointer data types) is
the default on all Solaris platforms and on Linux platforms that
are not 64-bit enabled. The LP64 memory model (64-bit long,
pointer data types) is the default on Linux platforms that are
64-bit enabled. -m64 is permitted only on platforms that are
enabled for the LP64 model.
Object files or libraries compiled with -m32 cannot be linked
with object files or libraries compiled with -m64.
When compiling applications with large amounts of static data
using -m64, -xmodel=medium may also be required.
Be aware that some Linux platforms do not support the medium
model.
Note that in previous compiler releases, the memory model, ILP32
or LP64, was implied by the choice of the instruction set with
-xarch. Starting with the Sun Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the
command line is sufficient to create 64-bit objects.
On Solaris, -m32 is the default. On Linux systems supporting
64-bit programs, -m64 -xarch=sse2 is the default.
See also -xarch.
-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.
-g suppresses automatic inlining. In general, -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.
The -xcrossfile option is effective only if it is used
with -O4 or -O5.
See also: -fast, -xprofile=p, csh(1) man page
-o nm Specify the name of the executable file to be written
There must be a blank between -o and nm. Without this option,
the default is to write the executable to a.out. When used with
-c, -o specifies the target .o object file; with -G it specifies
the target .so library file.
-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).
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 Solaris
platforms or just gprof on 32 bit Solaris platforms include
approximate user CPU times. These times are derived from PC
sample data (see pcsample(2)) for routines in the main
executable and routines in shared libraries specified as linker
arguments when the executable is linked. Other shared libraries
(libraries opened after process startup using dlopen(3DL)) are
not profiled.
On 32 bit Solaris systems, profiles generated using prof(1) are
limited to routines in the executable. 32 bit shared libraries
can be profiled by linking the executable with -xpg and using
gprof(1).
The Solaris 10 software does not include system libraries
compiled with -p. As a result, profiles collected on Solaris 10
platforms do not include call counts for system library
routines.
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.
-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</f3/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 -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.
-sb (Obsolete) Produce table information for the source browser.
The source browser is no longer supported. This option is
ignored.
-sbfast
(Obsolete) Similar to -sb, but faster.
The source browser is no longer supported. This option is
ignored.
-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 a
% limit stacksize 65536
command.
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}]
Permit 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.
-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, when -vax= is not specified, is -vax=%all.
-vpara Show parallelization warning messages
Issues warnings about potential parallel programming related
problems that may cause incorrect results when using OpenMP or
Sun/Cray parallel directives and pragmas.
Use with with -xopenmp and OpenMP API directives, or with
-explictpar and C$MIC DOALL parallelization directives.
Warnings are issued when the compiler detects the following
situations:
o Loops that are parallelized using C$MIC DOALL directives
when there are data dependencies between different loop
iterations
o 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: Sun Studio compilers support OpenMP 2.5 API
parallelization. Consequently, the MP pragmas and C$MIC
directives are deprecated. See the OpenMP API User's Guide for
information on migrating to the OpenMP API.
-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.
-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.
-xa Synonym for -a.
-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
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}]
(Solaris Only) Instructs the compiler to create binaries that
can later be transformed by binary modification tools like
binopt(1). Future binary analysis, code coverage and memory
error detection tools will also work with binaries built with
this option.
Use the -xannotate=no option to prevent the modification of the
binary file by these tools.
The -xannotate=yes option must be used with optimization level
-xO1 or higher to be effective, and it is only effective on
systems with the new linker support library interface -
ld_open(). If the compiler is used on a system without this
linker interface (for example Solaris 9 and early versions of
Solaris 10), it silently will revert to -xannotate=no.
The default is -xannotate=yes, but if either of the above
conditions is not met, the default reverts to -xannotate=no.
This options 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: 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.
Values (all platforms):
Value Meaning
generic Compile using the instruction set common to most
processors.
generic64 Compile for most 64-bit platforms. (Solaris only)
This option is equivalent to
-m64 -xarch=generic
and is provided for compatibility with earlier
releases. Use -m64 to specify 64-bit compilation
instead of -xarch=generic64
native Compile for good performance on this system
The compiler chooses the appropriate setting for the
current system processor it is running on.
native64 Compile for good performance on this system (Solaris
only)
This option is equivalent to
-m64 -xarch=native
and is provided for compatibility with earlier
releases.
Values on 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.
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.
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 for x86 platforms:
Value Meaning
386 Limits the instruction set to the Intel 32-bit 386/486
architecture.
pentium_pro
Limits the instruction set to the 32-bit pentium_pro
architecture.
sse Adds the SSE instruction set to the pentium_pro
instruction set.
sse2 Adds the SSE2 instruction set to the pentium_pro
instruction set.
amd64 Is equivalent to -m64 -xarch=sse2 (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 (Solaris only)
sse3 Adds the SSE3 instruction set to SSE2 instruction set.
ssse3 Adds the SSSE3 instruction set to the SSE3 instruction
set.
Notes: 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
(http://developer.intel.com/products/processor/manuals/)
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=sparc on SPARC platforms
-xarch=386 on x86 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=sparcvis -xcache=64/32/4:8192/128/2 -xchip=ultra4
In the following command
example% f95 -xtarget=ultra4 -xarch=sparcvis2 ...
-xarch=sparcvis2 overrides the -xarch setting in the expansion
of -xtarget=ultra2.
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) 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 for optimizer
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.
-xcg89 (SPARC) Synonym for -cg89.
This option is obsolete and should not be used.
-xcg92 (SPARC) Synonym for -cg92.
This option is obsolete and should not be used.
-xcheck=v
Perform special run-time checks.
v may be chosen from:
%all %none stkovf no%stkovf init_local no%init_local
Note: Only -xcheck=init_local is accepted on x86 platforms.
%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
(SPARC only) 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.
SAVE variables, module variables, and variables in COMMON
blocks are not initialized. no%init_local disables this
initialization and is the default.
-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.
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.
generic Optimize for good performance on most supported
SPARC platforms. (This is the compiler
default.)
native Optimize for good performance on this host
platform.
Less common SPARC processor names:
super Optimize for the SuperSPARC chip.
super2 Optimize for the SuperSPARC II chip.
micro Optimize for the MicroSPARC(TM) chip.
micro2 Optimize for the MicroSPARC II chip.
hyper Optimize for the HyperSPARC(TM) chip.
hyper2 Optimize for the HyperSPARC II chip.
The -xchip values on x86 platforms are:
core2 Optimize for Intel Core2.
opteron
Optimize for AMD Opteron.
pentium
Optimize for Pentium.
pentium_pro
Optimize for Pentium Pro.
pentium3
Optimize for Pentium III.
pentium4
Optimize for Pentium 4.
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 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
-xcrossfile[=n]
(Obsolete) Enable optimization and inlining across source files
This option is now obsolete and should not be used.
It now has the same effect as -xipo. Use -xipo instead.
-xdebugformat={stabs|dwarf}
The Sun Studio compilers have migrated the format of debugger
information from the "stabs" format to the "dwarf" format. The
default setting for this release is -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 Sun 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 Sun 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, Sun 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=h
Show options summary or README file.
h is either readme or flags.
readme: Show the online README file.
flags: Show the compiler flags (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 Sun 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}]
(SPARC) 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
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. Unlike -xcrossfile, -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
Do not use with -xcrossfile. If used together a compilation
error will result.
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}
(SPARC) 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.
If you do not specify a setting for -xipo_archive, the compiler
assumes -xipo_archive=none.
-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
-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 link to the BLAS routines in 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.
-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
Link with the Sun Performance Library
Example:
f95-o pgx -fast pgx.f -xlic_lib=sunperf
As with -l it should appear after all source and object file
names on the command line. This option must be used 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.95
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 C$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 on 32-bit SPARC platforms
-xmemalign=8s on 64-bit SPARC platforms for C and C++
-xmemalign=8f on 64-bit SPARC platforms for Fortran
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
Solaris x64 platforms.
The -xmodel option enables the compiler to create 64-bit shared
objects for the Solaris x64 platforms and should only be
specified for the compilation of such objects.
This option is valid only when -m64 is 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
2.5 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 string to be 200525.
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.
To run a parallelized program in a multithreaded environment,
you must set the OMP_NUM_THREADS environment variable prior to
execution. This variable tells the runtime system the maximum
number of threads the program can create. The default is 1. In
general, set OMP_NUM_THREADS to the available number of virtual
processors on the running system, which can be determined by
using the Solaris psrinfo(1) command.
To enable nested parallelism, you must set the OMP_NESTED
environment variable to TRUE. Nested parallelism is disabled by
default. See the Sun Studio OpenMP API User's Guide 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 Sun 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 Solaris OS on the
target platform, as returned by getpagesize(3C). If you do not
specify a valid page size, the request is silently ignored at
run-time. The Solaris OS offers no guarantee that the page size
request will be honored.
Note: 1G support on x86/x64 platforms was added with Solaris 10
5/08. Compiler support was introduced in Sun Studio 12 patch
126498-02.
You can use pmap(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 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.
You must specify a valid page size for the Solaris OS on the
target platform, as returned by getpagesizes(3C). If you do not
specify a valid page size, the request is silently ignored at
run-time.
Note that this feature is not available on Solaris OS 7 and 8
environments.
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. You must specify a
valid page size for the Solaris OS on the target platform, as
returned by getpagesizes(3C). If you do not specify a valid
page size, the request is silently ignored at run-time.
Note that this feature is not available on Solaris OS 7 and 8
environments.
See -xpagesize for further details.
-xpec[={yes|no}]
Generate a PEC (Portable Executable Code) binary.
PEC binaries may be used with Automatic Tuning System, ATS. More
information about ATS is available here:
http://cooltools.sunsource.net/ats/index.html.
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.
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:
C$PRAGMA SUN_PREFETCH_READ_ONCE (address)
C$PRAGMA SUN_PREFETCH_READ_MANY (address)
C$PRAGMA SUN_PREFETCH_WRITE_ONCE (address)
C$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.
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. See the Fortran User's Guide for a complete list of
options that must be specified at both compile time and link
time.
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, profile data are
stored in a directory named program.profile where program
is the basename of the profiled process's main program.
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
You can set the environment variables SUN_PROFDATA and
SUN_PROFDATA_DIR to control where a program compiled with
-xprofile=collect stores the profile data. If set, the
-xprofile=collect data is written to
SUN_PROFDATA_DIR/SUN_PROFDATA.
These environment variables similarly control the path and
names of the profile data files written by tcov , as
described in the tcov(1) man page.
If these environment variables are not set, the profile
data is written to profdir.profile/feedback 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
feedback file; that is, output from prior executions is not
lost.
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. For a complete list
of compiler options that must be specified at both compile
time and at link time, see the Fortran User's Guide.
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] 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].
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
Basic block coverage analysis using "new" style tcov.
The -xprofile=tcov option is the new style of basic block
profiling for tcov. It has similar functionality to the -xa
option, but correctly collects data for programs that have
source code in header files. See also -xa for information
on the old style of profiling, the tcov(1) man page, and
the Performance Analyzer manual for more details.
Code instrumentation is performed similarly to that of the
-xa option, but .d files are no longer generated. instead,
a single file is generated, the name of which is based on
the final executable. for example, if the program is run
out of /foo/bar/myprog.profile, the data file is stored in
/foo/bar/myprog.profile/myprog.tcovd.
When running tcov, you must pass it the -x option to make
it use the new style of data. If not, tcov uses the old .d
files, if any, by default for data, and produces unexpected
output.
Unlike the -xa option, the TCOVDIR environment variable has
no effect at compile-time. However, its value is used at
program runtime. See tcovf1(1) and the Performance
Analyzer manual for more details.
Note: tcov's code coverage report can be unreliable if
functions are inlined due to the use of -xO4 or higher
optimization or -xinline.
Counter values generated by -xprofile=tcov are not
guaranteed to be accurate in multi-threaded applications,
because if two threads simultaneously attempt to increment
the same counter, one of the increments may be lost.
However, since increments do not cancel one another, the
resulting data are still valid for coverage analysis.
-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.c t2.c
a.out // run collects feedback data
f95-xO5 -xprofile=use -xprofile_ircache t1.c t2.c
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
Specify register usage
Specify usage of registers in generated code.
r is a comma-separated list of one or more of the following:
[no%]appl, [no%]float, [no%]frameptr .
Example: -xregs=appl,no%float
Precede the suboption with [no%] to disable the feature.
The -xregs values are for specific -xarch values):
appl (SPARC only)
Allow the compiler to generate code using the
application registers as scratch registers. The
registers are g2, g3, and g4 on 32-bit platforms, and
g2, g3 on 64-bit platforms.
float (SPARC only)
Allow the compiler to generate code using the floating-
point registers as scratch registers for integer
values. This option has no effect on the use of
floating-point registers for floating-point values.
frameptr (x86 only)
Allow the compiler to use the frame-pointer register
(%ebp on x86 32-bit platforms, %rbp on x86 64-bit
platforms) as an unallocated callee-saves register.
Using this register as an unallocated callee-saves
register may improve program run time. However, it also
reduces the capacity of some tools, such as the
Performance Analyzer and dtrace, to inspect and follow
the stack. This stack inspection capability is
important for system performance measurement and
tuning. Therefor, using this optimization may improve
local program performance at the expense of global
system performance.
frameptr is ignored when also compiling with -xpg or
-p.
The default is: -xregs=appl,float on SPARC,
-xregs=appl,float,no%frameptr, on x86.
It is strongly recommended that you compile code intended for
shared libraries that will link with applications, with
-xregs=no%appl,float. At the very least, the shared library
should explicitly document how it uses the application registers
so that applications linking with those libraries know how to
cope with the issue.
For example, an application using the registers in some global
sense (such as using a register to point to some critical data
structure) would need to know exactly how a library with code
compiled without -xregs=no%appl is using the application
registers in order to safely link with that library.
-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, for both -m32, and -m64.
-xsb
Synonym for -sb. (Obsolete and ignored).
-xsbfast
Synonym for -sbfast. (Obsolete and ignored).
-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,
sparc64vi, sparc64vii.
The following target platforms are equivalent to -xtarget=ultra
entr2, entr2/1170, entr2/2170, entr2/1200, entr2/2200,
entr3000, entr4000, entr5000, entr6000
Less commonly used platform names:
sun4/15, sun4/30, sslc, sslx, sslx2, ss4, ss4/85, ss4/110, ss5,
ss5/85, ss5/110, ssvyger, ss10, ss10/hs11, ss10/hs12,
ss10/hs14, ss10/20, ss10/hs21, ss10/hs22, ss10/30, ss10/40,
ss10/41, ss10/50, ss10/51, ss10/61, ss10/71, ss10/402,
ss10/412, ss10/512, ss10/514, ss10/612, ss10/712, ss20,
ss20/hs11, ss20/hs12, ss20/hs14, ss20/hs21, ss20/hs22, ss20/50,
ss20/51, ss20/61, ss20/71, ss20/151, ss20/152, ss20/502,
ss20/512, ss20/514, ss20/612, ss20/712, ss600/41, ss600/51,
ss600/61, ss600/412, ss600/512, ss600/514, ss600/612, ss1000,
sc2000, cs6400, solb6
Compiling for a 64-bit 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, and opteron.
Compiling for 64-bit 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[=[[no%]lib,[no%]simd, %none] ]
Enable automatic generation of calls to the vector library
functions.
This option requires compiling with default rounding mode
-fround=nearest when compiling with -xvector.
-xvector=lib (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. -xvector=no%lib disables this feature.
-xvector=simd enables the compiler to use the native x86 SSE SIMD
instructions to improve performance of certain loops. The compiler
can only accept this switch if the target architecture supports
SIMD instructions. For example, you must specify -xarch=sse2 -m64
or -xarch=generic64. You must also specify an optimization level
of -xO3 or above as well as -xdepend with -xvector=simd.
-xvector=no%simd disables this feature.
You will get better performance if you specify both -xvector=simd
and -fsimple=2 than with -xvector=simd alone. However, your
floating point results can be slightly different because -fsimple=2
allows reordering of floating-point operations.
The default is -xvector=%none. If you specify -xvector, but do not
provide a flag, the compiler assumes -xvector=lib.
The compiler includes the libmvec libraries in the load step. If
you specify -xvector=lib at compile time, you must also specify it
at link time.
This option overrides previous instances so -xvector=%none
overrides a previously specified -xvector=lib.
-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, !$PRAGMA, or *$PRAGMA, and any uppercase or
lowercase is allowed.
C$PRAGMA C(list_of_subprogram_names)
C$PRAGMA SUN UNROLL n
C$PRAGMA WEAK function_name
C$PRAGMA SUN OPT=n
C$PRAGMA PIPELOOP=n
C$PRAGMA SPARC_PREFETCH_READ_ONCE (name)
C$PRAGMA SPARC_PREFETCH_READ_MANY (name)
C$PRAGMA SPARC_PREFETCH_WRITE_ONCE (name)
C$PRAGMA SPARC_PREFETCH_WRITE_MANY (name)
C$PRAGMA SUN_PREFETCH_READ_ONCE (name)
C$PRAGMA SUN_PREFETCH_READ_MANY (name)
C$PRAGMA SUN_PREFETCH_WRITE_ONCE (name)
C$PRAGMA SUN_PREFETCH_WRITE_MANY (name)
!$PRAGMA IGNORE_TKR list
C$PRAGMA ASSUME (expression [, probability])
Parallelization Directives: f95 recognizes the OpenMP API
parallelization directives. OpenMP is the recommended model for
explicit parallelization for all the Sun 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 Sun Studio OpenMP implementation, see
the OpenMP API User's Guide.
f95 (on SPARC only) also recognizes legacy Sun-style and Cray-style
parallelization directives, although these directives are deprecated an
no longer supported. (Sun/Cray parallelization directives are not
recognized on x86.) See the OpenMP API User Guide for details on
converting Sun/Cray directives to OpenMP. Sun-style compiler directive
lines starting with C$PAR, !$PAR, or *$PAR, and any uppercase or
lowercase is allowed.
C$PAR DOALL
C$PAR DOSERIAL
C$PAR DOSERIAL*
C$PAR TASKCOMMON
Cray-style parallelization directives are also recognized. The
directive sentinel is CMIC$ or !MIC$
CMIC$ DOALL
CMIC$ TASKCOMMON
CMIC$ DOSERIAL
CMIC$ DOSERIAL*
See the Fortran User's Guide for details and variations.
See also the OpenMP API User's Guide for guidelines on converting
legacy Sun/Cray paralellization to OpenMP API directives.
ENVIRONMENT
The paths shown below assume the root of the Sun 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 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]
Asynchronous profile collection requires OpenSolaris 2009.06 or later.
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}
If set, specifies the subset of data in the profile directory to be
reset if a program change is detected at runtime when the current
process's profile data are merged with data already stored in the
profile directory. If not set, the subset of profile data to be reset
is determined by the optimization flags specified with
-xprofile=collect. 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 Sun 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
Sun math lib
libsunimath
Sun 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
OpenSolaris and Solaris releases.
READMEs
A number of README files provide valuable last-minute information on
Sun Studio compilers and tools and libraries. Of particular interest
are:
o fortran_95
o math_libraries
The Sun Studio readmes for this release can be found on the Sun Studio
portal at:
http://developers.sun.com/sunstudio/documentation/ss12/index.html
SEE ALSO
An index to the complete Sun Studio documentation can be found by
pointing an HTML browser at the following URL:
http://developers.sun.com/sunstudio/documentation/
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
Sun Performance Library User's Guide
Sun Studio Performance Analyzer
Fortran Library Reference
Solaris OS Linker and Libraries Guide
Debugging a Program With dbx
Sun Performance Library User's Guide: This Sun 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 Sun Studio Developer Network
web site:
http://developers.sun.com/sunstudio/
DIAGNOSTICS
The diagnostics produced by f95 itself are intended to be self-
explanatory. Occasional messages can be produced by the linker.
April 2009 f95(1)