svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
f95(1)
f95(1) User Commands f95(1)
NAME
f95, f90 - Fortran 95 compiler
SYNOPSIS
Can be invoked by either f95 or f90 commands; they are
equivalent.
f95 [ -aligncommon[=a] ] [ -ansi ] [ -arg=local ]
[ -autopar ] [ -Bx ] [ -C ] [ -c ]
[ -copyargs ] [ -Dnm[=def] ] [ -dalign ]
[ -dbl_align_all[={yes|no}] ] [ -depend[={yes|no}] ]
[ -dryrun ] [ -d{y|n} ] [ -e ] [ -erroff[=taglist] ]
[ -errtags[={yes|no}] ] [ -errwarn[=taglist] ]
[ -ext_names=e ] [ -F ] [ -f ]
[ -f77[=list] ] [ -fast ] [ -features=a ] [ -fixed ] [ -flags ]
[ -fma={none|fused} ] [ -fnonstd ] [ -fns[={yes|no}] ]
[ -fpover[={yes|no}] ] [ -fpp ] [ -fopenmp ]
[ -fprecision=p ] [ -free ] [ -fround=r ]
[ -fserialio ] [ -fsimple[=n] ] [ -fstore ]
[ -ftrap=t ] [ -G ] [ -g ]
[ -g[n] ] [-gz[=cmp-type]] [ -hnm ] [ -help ] [ -Ipath ] [ -inline=rl ]
[ -iorounding[=r] ] [ -keepmod[={yes|no}] ]
[ -keeptmp ] [ -KPIC ] [ -Kpic ] [ -Lpath ] [ -lx ]
[ -libmil ] [ -library=sunperf ]
[ -loopinfo ] [ -Mpath ]
[ -m32|-m64 ] [ -moddir=path ] [ -mt ]
[ -native ] [ -noautopar ] [ -nodepend ]
[ -nofstore ] [ -nolib ]
[ -nolibmil ] [ -noreduction ] [ -norunpath ]
[ -O[n] ] [ -o nm ] [ -onetrip ]
[ -openmp[=a] ] [ -PIC ] [ -p ]
[ -pad[=a] ] [ -pg ] [ -pic ]
[ -preserve_argvalues[=int|none] ]
[ -Qoption pr ls ] [ -qp ] [ -R list ] [ -r8const ]
[ -recl=a[,b] ] [ -reduction ] [ -S ] [ -s ]
[ -shared] [-silent ] [ -stackvar ] [ -stop_status={yes|no} ]
[ -temp=path ] [ -time ] [ -traceback[=list] ]
[ -U ] [ -Uname ] [ -u ]
[ -unroll=n ] [ -use=list ] [ -V ] [ -v ] [ -vax=v ]
[ -vpara ] [ -Wc,arg ] [ -w[n] ]
[ -Xlinker arg ] [ -Xlist[z] ]
[ -xaddr32[={no|yes}] ] [ -xalias[=a[,a]...] ]
[ -xannotate[={yes|no}] ] [ -xarch=a ]
[ -xassume_control[=a[,a]...] ]
[ -xautopar ]
[ -xcache=c ] [ -xcheck=n ] [ -xchip=c ]
[ -xcode=v ] [ -xcommonchk[={no|yes}] ]
[-xcompress={[no%]debug}] [-xcompress_format=cmp-type]
[ -xdebugformat=dwarf ]
[ -xdebuginfo=a[,a...] ] [ -xdepend ]
[ -xdryrun ] [ -xF ] [ -xfilebyteorder=options ]
[ -xglobalize[={yes|no}] ]
[ -xhasc[={yes|no}] ] [ -xhelp=h ]
[ -xhwcprof[=e] ] [ -xinline=rl ]
[ -xinline_param=a[,a[,a]...] ] [ -xinline_report[=n] ]
[ -xinstrument=d ]
[ -xipo[=n] ] [ -xipo_archive=a ]
[ -xipo_build=[yes|no] ] [ -xivdep[=p] ]
[ -xjobs=[n|auto] ]
[ -xkeep_unref[={[no%]funcs, [no%]vars}] ]
[ -xkeepframe[=p] ]
[ -xknown_lib=lib ] [ -xl ] [ -xld ] [ -xlang=f77 ]
[ -xlibmil ] [ -xlibmopt ]
[ -xlinkopt[=level] ]
[ -xloopinfo ] [ -xM ] [ -xmaxopt[=n] ]
[ -xmemalign[=ab] ] [ -xmodel=[a] ] [ -xnolib ]
[ -xnolibmil ] [ -xnolibmopt ] [ -xO[n] ]
[ -xopenmp[=a] ] [ -xpad[=a] ] [ -xpagesize=n ]
[ -xpagesize_heap=n ] [ -xpagesize_stack=n ]
[ -xpatchpadding[={fix|patch|size}] ]
[ -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[={yes|no}] ] [ -xsafe=mem ]
[ -xsecure_code_analysis{=[yes|no] ] [-xsegment_align=n]
[ -xspace ] [ -xtarget=t ] [ -xtemp=path ]
[ -xthroughput[={yes|no}] ] [ -xtime ]
[ -xtypemap=spec ] [ -xunboundsym={yes|no} ]
[ -xunroll=n ] [ -xvector[={v}] ] [ -xvpara ]
[ -ztext ] source file(s) ... [ -lx ]
DESCRIPTION
Oracle Developer Studio 12.6 Fortran 95 compiler, version 8.8.
The f95 compiler accepts standard-compliant Fortran 95 source code pro‐
grams. It also accepts some Fortran 2003 features, and the OpenMP[tm]
Fortran 95 API version 3.1. It also accepts many FORTRAN 77 (f77) lan‐
guage extensions under the -f77 compatibility option, and VAX VMS For‐
tran extensions (-vax).
Version 8.8 of the Fortran 95 compiler f95 is released as a component
of Oracle Developer Studio 12.6, and is available for the Oracle
Solaris Operating System (Oracle Solaris OS) on SPARC and x86 plat‐
forms, and on Linux x86 platforms.
See the Oracle Developer Studio 12.6:
Release Notes for a complete list of system environments and
versions.
Complete documentation for this release is available on the Oracle
Technical Network (OTN) Oracle Developer Studio website: http://ora‐
cle.com/technetwork/server-storage/developerstudio.
The OTN website is a complete resource for Oracle Developer Studio and
includes many technical articles detailing best practices and deep
dives into various programming technologies and other topics.
For the full description of all new features and functionality in the
Oracle Developer Studio suite, see What's New in the
Oracle Developer Studio 12.6 Release.
A man page, by definition, is a quick reference. For more detailed
information on using the f95 compiler and its options, see the Oracle
Developer Studio 12.6: Fortran
User' Guide and the Fortran Programming
Guide.
See the Oracle Developer Studio 12.6:
Fortran User' Guide for complete details on how to use the
f95 compiler. The user guide details all the options, pragma direc‐
tives, 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 perfor‐
mance and optimization, parallelization, and porting from other Fortran
platforms.
A list of relevant Oracle Developer Studio documentation appears at the
end of this man page.
Compiling for 64-Bit Platforms
Use the -m32 and -m64 options to specify the data type model of the
target compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit data type model defini‐
tion, and should be used only to specify the instruction set of the
target processor.
The ILP32 model specifies that C-language int, long, and pointer data
types are each 32-bits wide. The LP64 model specifies that long and
pointer data types are each 64-bits wide and int is 32-bits wide. The
Oracle Solaris and Linux OS also support large files and large arrays
under the LP64 data type model.
When compiling with -m64, the resulting executable will work only on
64-bit SPARC or x86 processors under Oracle Solaris OS or Linux OS run‐
ning a 64-bit kernel. Compilation, linking, and execution of 64-bit
objects can only take place in a Oracle Solaris or Linux OS that sup‐
ports 64-bit execution.
Special x86 Notes
There are some important issues to be aware of when compiling for x86
Oracle Solaris platforms.
Programs compiled with -xarch set to sse2, sse2a, or sse3 and beyond
must be run only on platforms that provide these extensions and fea‐
tures.
With this release, the default instruction set and the meaning of
-xarch=generic has changed to sse2. Now, compiling without specifying a
target platform option results in an sse2 binary incompatible with
older Pentium III or earlier systems.
If you compile and link in separate steps, always link using the com‐
piler and with same -xarch setting to ensure that the correct startup
routine is linked.
Numerical results can also differ between Oracle Solaris and Linux
because the intrinsic math libraries (for example, sin(x)) are not the
same.
Binary Compatibility Verification
Program binaries compiled and built using specialized -xarch hardware
flags are verified that they are being run on the appropriate platform.
Running programs compiled with specialized -xarch options on platforms
that are not enabled with the appropriate features or instruction set
extensions could result in segmentation faults or incorrect results
occurring without any explicit warning messages.
On Linux, however, there is no such verification check. Running binary
objects compiled by Oracle Developer Studio compilers on older hardware
platforms could result in runtime failures; on Linux it is the user's
responsibility to deploy these binaries on suitable hardware platforms.
This warning extends also to programs that employ .il inline assembly
language functions or __asm() assembler code that utilize SSE2, SSE2a,
and SSE3 (and beyond) instructions and extensions.
User-Supplied Default Compiler Options Startup File
The default compiler options file enables the user to specify a set of
default options that are applied to all compiles, unless otherwise
overridden. For example, the file could specify that all compiles
default at -xO2, or automatically include the file setup.il.
At startup, the compiler searches for a default options file listing
default options it should include for all compiles. The environment
variable SPRO_DEFAULTS_PATH specifies a colon-separated list of direc‐
tories to search for the the defaults file.
If the environment variable is not set, a standard set of defaults is
used. If the environment variable is set but is empty, no defaults are
used.
The defaults file name must be of the form compiler.defaults, where
compiler is one of the following: cc, c89, c99, CC, ftn, or lint. For
example, the defaults for the Fortran compiler would be ftn.defaults
If a defaults file for the compiler is found in the directories listed
in SPRO_DEFAULTS_PATH, the compiler will read the file and process the
options prior to processing the options on the command line. The first
defaults file found will be used and the search terminated.
System administrators may create system-wide default files in Studio-
install-path/lib/compilers/etc/config. If the environment variable is
set, the installed defaults file will not be read.
The format of a defaults file is similar to the command line. Each line
of the file may contain one or more compiler options separated by white
space. Shell expansions, such as wild cards and substitutions, will not
be applied to the options in the defaults file.
The value of the SPRO_DEFAULTS_PATH and the fully expanded command line
will be displayed in the verbose output produced by options -#, -###,
and -dryrun.
Options specified by the user on the command line will usually override
options read from the defaults file. For example, if the defaults file
specifies compiling with -xO4 and the user specifies -xO2 on the com‐
mand line, -xO2 will be used.
Some options appearing in the default options file will be appended
after the options specified on the command line. These are the pre‐
processor option -I, linker options -B, -L, -R, and -l, and all file
arguments, such as source files, object files, archives, and shared
objects.
The following is an example of how a user-supplied default compiler
option startup file might be used.
demo% cat /project/defaults/ftn.defaults
-fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
demo% setenv SPRO_DEFAULTS_PATH /project/defaults
demo% f95 -c -I/local/hdrs -L/local/libs -lliblocal tst.f
The compiler command is now equivalent to:
f95 -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.f -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way to set the
defaults for an entire project, it can become the cause of hard to
diagnose problems. Set the environment variable SPRO_DEFAULTS_PATH to
an absolute path rather than the current directory to avoid such prob‐
lems.
The interface stability of the default options file is uncommitted. The
order of option processing is subject to change in a future release.
OPTIONS
Options valid only on SPARC platforms are marked (SPARC).
Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be used going
forward. They are provided only for compatibility with earlier
releases. Use the indicated replacement option.
See ld(1) for linker options.
f95 compiles "silently". Except for error and warning messages, it does
not issue "progress" messages during compilation.
In general, processing of the compiler options is from left to right,
permitting selective overriding of macro options. This rule does not
apply to linker or preprocessor options.
In the syntax of the command-line options, items shown in square brack‐
ets ( [] ) 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.
The following options are supported:
-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 bound‐
aries.
Specifying -aligncommon without a value defaults to 1 on all plat‐
forms: All data aligns on byte boundaries (no padding between ele‐
ments).
-aligncommon=16 reverts to -aligncommon=8 when compiling with -m32.
Using -aligncommon=1 on SPARC platforms might result in a bus error
due to misalignment, requiring an appropriate choice of the -xmema‐
lign option be used. Depending on the application, -xmemalign=1s,
-xmemalign=4ior -xmemalign=8i should give optimal performance while
avoiding the segmentation fault.
See also: -xmemalign
-ansi
Identify nonstandard extensions.
-arg=local
Preserve actual arguments over ENTRY statements.
When you compile a subprogram with alternate entry points with this
option, f95 uses copy restore to preserve the association of dummy
and actual arguments.
This option is provided for compatibility with legacy Fortran 77
programs. Code that relies on this option is nonstandard.
-autopar
Turns on automatic loop parallelization. Analyzes loops for inter-
iteration data dependence) and loop restructuring. If optimization
is not at -O3 or higher, optimization is raised to -O3 and a warn‐
ing is issued.
Note that -autopar does not enable the recognition of OpenMP dire‐
cives. To enable the recognition of OpenMP directives, use the
-xopenmp compiler option.
Specify the -stackvar option when using -autopar. The -stackvar
option might provide better performance when using -autopar because
it might allow the optimizer to detect additional opportunities for
parallelization. See the Oracle Developer Studio 12.6: OpenMP API
User's
Guide for more information on how to set the sizes of
the main thread stack and the helper thread stacks.
Use the OMP_NUM_THREADS environment variable to specify the number
of threads to use when running a program automatically parallelized
by the -xautopar compiler option. If OMP_NUM_THREADS is not set,
the default number of threads used is a multiple of the number of
cores per socket (that is, cores per processor chip), which is less
than or equal to the total number of cores or 32, whichever is
less. You can specify a different number of threads by setting the
OMP_NUM_THREADS environment variable. For best performance, the
number of threads used should not exceed the number of hardware
threads (or virtual processors) available on the machine. On Oracle
Solaris systems, this number can be determined by using the
psrinfo(1M) command. On Linux systems, this number can be deter‐
mined by inspecting the file /proc/cpuinfo. See the Oracle Devel‐
oper Studio 12.6: OpenMP API User's
Guide for more information.
If you compile and link in separate steps, specify -autopar in both
the compilation step and the link step. When used with the link
step, the -autopar option will link with the OpenMP runtime support
library, libmtsk.so.
-B{dynamic|static}
Prefer dynamic or require static library linking.
This flag indicates that either dynamic library linking is pre‐
ferred, or static linking required for any libraries listed later
in the command. This is a linker option.
-Bdynamic Prefer dynamic linking (shared libraries).
-Bstatic Require static linking (no shared libraries).
The default is -Bdynamic.
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 -Bdynamic 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 -Bdy‐
namic requires the same options on a linker command if done in sep‐
arate steps.
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 unex‐
pected results, including segmentation faults. The -C option checks
for possible array subscript violations in the source code and dur‐
ing execution.
With the -C option specified, run-time array subscript violations
are treated as an error. The compiler will also flag array sub‐
script 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 debug‐
ging.
-c
Compile and produce a .o file for each source file without linking.
You can explicitly name a single object file by using the -o
option. When the compiler produces object code for each or input
file, it always creates an object file in the current working
directory. If you suppress the linking step, you also suppress the
removal of the object files.
-copyargs
Allow assignment to constant arguments.
Allow a subprogram to change a dummy argument that is a constant.
This option is provided only to allow legacy code to compile and
execute without a runtime error for changing a constant.
Without -copyargs, if you pass a constant argument to a subroutine,
and then within the subroutine try to change that constant, the run
gets a runtime error.
With -copyargs, if you pass a constant argument to a subroutine,
and then within the subroutine change that constant, the run does
not necessarily get a runtime error.
Programs that require compilation with the -copyargs flag are not
Fortran standard-compliant.
-Dname[=def]
Define symbol name for the source code preprocessor.
This is equivalent to a "#define" directive in the source. If no
def is given, name is defined as "1". This option applies to .F
.F90 .F95 .F03 suffix files only.
These predefined macros are used on the corresponding platforms:
__SUNPRO_F90=0x880
__SUNPRO_F95=0x880
__SVR4 (Oracle Solaris)
__SVR4__ (Oracle Solaris)
__SunOS (Oracle Solaris)
__SunOS_5_10 (Oracle Solaris)
__SunOS_5_11 (Oracle Solaris)
__amd64 (x86 -m64)
__amd64__ (x86 -m64)
__gnu__linux__ (linux)
__i386 (x86)
__i386__ (x86)
__linux (linux)
__linux__ (linux)
__sparc (SPARC)
__sparc__ (SPARC)
__sparc_v9__(SPARC -m64)
__sparcv8 (SPARC -m32)
__sparcv9 (SPARC -m64)
__sun (Oracle Solaris)
__sun__ (Oracle Solaris)
__svr4__ (Oracle Solaris)
__unix
__unix__
__x86_64 (x86 -m64)
__x86_64__ (x86 -m64)
i386 (x86)
linux (linux)
sparc (SPARC)
sun (Oracle Solaris)
unix
__SunOS_RELEASE (Oracle Solaris)
_LP64 (-m64)
__LP64__ (-m64)
A hex value 0xRRrrmm representing the Oracle Solaris release, where
RR.rr is the output of the sysinfo (SI_RELEASE) system call, or of
the uname -r command, with leading zeros added when needed. The mm
digits are reserved for possible future micro releases. All the
digits are decimal. Example for Oracle Solaris 11, which is SunOS
5.11: __SunOS_RELEASE, has the value, 0x051100. The value of
__SunOS_RELEASE for an older Oracle Solaris release is always less
than the value for a later release.
Fortran syntax might not support the actual values of these sym‐
bols. They should appear only on fpp or cpp preprocessor state‐
ments, 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 preproces‐
sor 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 gener‐
ate 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
Note that -aligncommon=16 is reverted to -aligncommon=8 when com‐
piled with --m32.
The data layout effect is that of the -f flag: double- and quad-
precision data in COMMON blocks and EQUIVALENCE classes are laid
out in memory along their "natural" alignment, which is on 8-byte
boundaries (or 16-byte boundaries for quad-precision when compiling
for 64-bit platforms with -m64.) The default alignment in COMMON
blocks and standard-conforming numeric sequence derived thpes 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 sub‐
programs 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.
Double precision and quad-precision data alignments are not
affected by this option.
This flag does not alter the layout of data in COMMON blocks or
user-defined structures.
-depend[=yes|no]
Analyze loops for data dependence and restructuring.
-depend is equivalent to -depend=yes and enables loop dependence
analysis. It is on by default on all platforms.
-depend=no disables DO loop data dependence analysis
-dryrun
Show commands built by the f95 driver but do not compile.
Useful when debugging, this option displays the commands the com‐
piler 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.
-dy Allow dynamic libraries.
-dn Do not allow dynamic libraries.
The default is -dy.
Unlike -B{dynamic|static}, this option applies to the whole exe‐
cutable 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.
-e
Extend source line maximum length to 250 characters.
The compiler pads on the right with trailing blanks to column 250.
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 speci‐
fied 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 warn‐
ing 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, underscores, or fsecond-underscore.
plain
Do not use trailing underscores.
underscores
Use trailing underscores.
fsecond-underscore
Append two underscores to external names that contain an under‐
score, and a single underscore to those that do not.
The default is underscores.
An external name is a name of a subroutine, function, block data
subprogram, or labeled common. This option affects both the name in
the routine itself and, of course, the name used in the calling
statement (both symdefs and symrefs).
fsecond-underscore is provided for compatibility with gfortran.
-F
Invoke the source file preprocessor, but do not compile
Apply the fpp preprocessor to .F90, .F95, .F03, and .F files and
put the result in the file with the suffix changed to .f90, .f95,
.f03,or .f, but do not compile.
fpp is the default preprocessor for Fortran. The C preprocessor,
cpp, can be selected instead by specifying -xpp=cpp.
-f
Align double- and quad-precision data in COMMON blocks.
This flag changes the data layout in COMMON blocks (and EQUIVALENCE
classes): double- and quad-precision data in COMMON blocks and
EQUIVALENCE classes are laid out in memory along their "natural"
alignment, which is on 8-byte boundaries (or on 16-byte boundaries
for quad-precision when compiling for 64-bit environments with
-m64). The default alignment of data in COMMON blocks is on 4-byte
boundaries.
-f is is a legacy option equivalent to -aligncommon=16. Use of
-aligncommon is preferred.
This option applies to both real and complex data.
Resulting code might not be standard and might not be portable.
If you compile one subprogram with -f, compile all subprograms of
the program with -f.
By itself, this option does not enable the compiler to generate
faster double word fetch/store instructions and double and quad
precision data. Only -dalign will do this.
-f77[=list]
Select Fortran 77 compatibility mode.
list is a comma-separated list selected from the following possible
keywords:
%all
Select all the f77 compatibility features.
%none
Disable the f77 compatibility features.
output
Generate f77-style formatted output, including list-directed
and namelist output.
input
Accept input formats allowed by f77.
tab
Enable f77-style TAB-formatting, including unlimited source
line length. Also, no blank padding will be added to source
lines shorter than 72 characters.
backslash
Accept a backslash character as the beginning of an escape
sequence in character strings.
intrinsics
Limit recognition of intrinsics to only Fortran 77 intrinsics.
logical
Accept Fortran 77 usage of logical variables, such as:
o Allow assignment of integer values to logical vari‐
ables.
o Allow arithmetic expressions in place of logical
expressions in conditional statements, with .NE.0
representing .TRUE..
o 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.
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. Spec‐
ify -ftrap=%none after -f77 to revert to trapping that mimics For‐
tran 77's behavior.
See the chapter on FORTRAN 77 compatibility in the Oracle Developer
Studio 12.6: Fortran User'
Guide for details on -f77 and the compatibility
features it provides. See also the -xalias flag for handling non‐
standard FORTRAN 77 programming that can cause incorrect results.
A Fortran 77 compiler script has been provided for convenience. The
f77 command-line script invokes the f95 compiler with the appropri‐
ate 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 per‐
formance 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 compi‐
lation machine, follow the -fast with the appropriate
-xtarget= option. For example:
f95 -fast -xtarget=generic ...
o -O5 selects optimization level 5.
o -libmil selects inlining of certain math library rou‐
tines.
o -fsimple=2 selects aggressive floating-point optimiza‐
tions. This option might be unsuited for programs
requiring strict IEEE 754 standards compliance.
o -dalign selects generation of faster double word
load/store instructions, and alignment of double and
quad data on their natural boundaries in common blocks.
Using this option might generate nonstandard Fortran
data alignment.
o -xlibmopt selects linking the optimized math library.
o -depend=yes selects dependence analysis to better opti‐
mize DO loops. (This option is always selected for opti‐
mization levels -O3 and greater.)
o -fma=fused enables automatic generation of floating-
point fused multiply-add instructions.
o -fns selects faster (but nonstandard) handling of float‐
ing-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 -xlib‐
mopt require it.
o -nofstore cancels forcing expressions to have the preci‐
sion of the result. (x86)
o -xregs=frameptr on x86 allows the compiler to use the
frame-pointer register as a general-purpose register. Be
sure to read the discussion of -xregs=frameptr espe‐
cially when compiling mixed C, Fortran, and C++ source
codes. Specify -xregs=no%frameptr after -fast and the
frame pointer register will not be used as a general
purpose register. (x86)
Note that this selection of component option flags is subject to
change with each release of the compiler. For details on the
options set by -fast, see the Oracle Developer Studio 12.6:
Fortran User' 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 -xlibmopt=%none
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 float‐
ing-point arithmetic, nonstandard alignment of data, and nonstan‐
dard 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.
-features=a
Enables/disables the following Fortran language feature.
[no%]mergestrings
(SPARC) Causes the compiler to put string literals and other
suitable const or read-only data into a special section of the
binary where the linker removes duplicate strings.
The default is -features=no%mergestrings, and duplicate strings
are not removed.
-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}]
Enables 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.
The minimum architecture requirement is -xarch=sparcfmaf on SPARC
and -xarch=avx2 on x86 to generate fused multiply-add instructions.
The compiler marks the binary program if fused multiply-add
instructions are generated in order to prevent the program from
executing on platforms that do not support fused multiply-add
instructions. When the minimum architecture is not used, then
-fma=fused has no affect.
Fused multiply-add instructions eliminate the intermediate rounding
step between the multiply and add. Consequently, programs may pro‐
duce different results when compiled with -fma=fused although pre‐
cision will tend to increase rather than decrease.
-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 denormal‐
ized numbers.
The -fnonstd option enables hardware traps for floating-point over‐
flow, 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), the Oracle
Developer Studio 12.6: Numerical Computation Guide,
and Fortran Programming Guide for more information.
-fns[={yes|no}]
Select nonstandard floating point.
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 non-standard float‐
ing-point. The default, -fns=no, utilizes standard floating-point
mode.
-fast selects -fns.
On SPARC platforms, nonstandard floating point mode disables "grad‐
ual 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 opera‐
tions not utilizing the SSE or SSE2 instruction set.
Warning: When nonstandard mode is enabled, floating point arith‐
metic can produce results that do not conform to the requirements
of the IEEE 754 standard. See the Oracle Developer Studio 12.6:
Numerical
Computation Guide and the Oracle Developer Studio
12.6: Fortran User'
Guide for more information.
This option is effective only if used when compiling the main pro‐
gram.
-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 excep‐
tion. 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
-fopenmp
Same as -xopenmp=parallel.
-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 pro‐
gram initiation. When p is extended or the -fprecision flag is not
used, the rounding precision mode is initialized to extended preci‐
sion.
This option is effective only on x86 systems and only if used when
compiling the main program, but is ignored if compiling for 64-bit
platforms (-m64), or SSE2-enabled processors (-xarch=sse2). -fpre‐
cision is ignored on SPARC platforms.
-free
Assume free-format source input.
Interpret all source files as Fortran 95 free-format. Overrides the
file suffix.
-fround=r
Select the IEEE rounding mode in effect at startup.
r must be one of: nearest, tozero, negative, or positive
The default is -fround=nearest.
When r is tozero, negative, or positive this flag causes the round‐
ing direction mode to be set to round-to-zero, round-to-negative-
infinity, or round-to-positive-infinity respectively when the pro‐
gram 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 pro‐
gram.
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.
-fserialio
A linking option that specifies that the program does not perform
I/O in more than one thread at a time. It allows Fortran I/O state‐
ments to be executed without performing synchronization to avoid
race conditions. This option should be specified only when creating
an executable program. It should not be specified when creating a
shared object library.
-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.
If -fsimple is not specified, f95 uses -fsimple=0. If only -fsimple
is specified, 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.
With -fsimple=1, the optimizer can assume the following:
o IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computations producing no visible result other than
potential floating point exceptions might be
deleted.
o Computations with Infinity or NaNs as operands need
not propagate NaNs to their results; e.g., x*0 might
be replaced by 0.
o Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optimize com‐
pletely without regard to roundoff or exceptions. In particu‐
lar, a floating-point computation cannot be replaced by one
that produces different results with rounding modes held con‐
stant 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 pro‐
grams 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.
-fsimple=2 allows fp-transformations which may introduce fp
exceptions.
-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:
[no%]division
[Do not] Trap on division by zero.
[no%]inexact
[Do not] Trap on inexact result.
[no%]invalid
[Do not] Trap on invalid operation.
[no%]overflow
[Do not] Trap on overflow.
[no%]underflow
[Do not] Trap on underflow.
%all
Trap on all the above.
%none
Trap on none of the above.
common
Trap on invalid, division by zero, and overflow.
Note that the [no%] form of the option is used only to modify the
meanings of the %all or common value and must be used with one of
these values, as shown in the exam ple. The [no%] form of the
option by itself does not explicitly cause a particular t rap to be
disabled.
To be effective this option must be used when compiling the main
program.
-fvisibility
The âfvisibility=v option is equivalent to the -xldscope option as
follows:
-fvisibility=default -fvisibility=default is equivalent to
-xldscope=global
-fvisibility=internal -fvisibility=internal is equivalent to
-xldsdope=hidden
-fvisibility=protected -fvisibility=protected is equivalent to
-xldscope=symbolic
-fvisibility=hidden -fvisibility=hidden is equivalent to
-xldscope=hidden
-G
Produce a shared object rather than a dynamically linked exe‐
cutable. This option is passed to ld and cannot be used with the
-dn option.
When you use the -G option, the compiler does not pass any default
-l options to ld. If you want the shared library to have a depen‐
dency on another shared library, you must pass the necessary -l
option on the command line.
If you are creating a shared object by specifying -G along with
other compiler options that must be specified at both compile time
and link time, make sure that those same options are also specified
when you link with the resulting shared object. For more informa‐
tion, see the -shared option.
When you create a shared object, all the object files that are com‐
piled for 64-bit SPARC architectures must also be compiled with an
explicit -xcode value as documented under the description of
-xcode.
-g
See -g[n].
-g[n]
Compile for debugging and performance analysis.
Produce additional symbol table information for debugging with
dbx(1) or the Oracle Developer Studio Debugger, and for analysis
with the Oracle Developer Studio Performance Analyzer, analyzer(1).
Although some debugging is possible without specifying -g, the full
capabilities of dbx are only available to those objects compiled
with -g.
To use the full capabilities of the Oracle Developer Studio Perfor‐
mance Analyzer, compile with -g. While some performance analysis
features do not require -g, you must compile with -g to view anno‐
tated source, some function level information, and compiler commen‐
tary messages. (See the analyzer(1) man page.)
The commentary messages generated with -g describe the optimiza‐
tions 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.
-g is implemented as a macro that expands to various other, more
primitive, options. See -xdebuginfo for the details of the expan‐
sions.
Values:
-g Produce standard debugging information.
-gnone Do not produce any debugging information. This is the
default.
-g1 Produce file and line number as well as simple parame‐
ter information that is considered crucial during
post-mortem debugging.
-g2 Same as -g.
-g3 Produce additional debugging information, which cur‐
rently consists only of macro definition information.
This added information can result in an increase in
the size of the debug information in the resulting .o
and executable when compared to using only -g.
-gz[=cmp-type]
Equivalent of specifying -xcompress=debug -xcompress_format=cmp-
type.
-gz with no sub-option is equivalent to -gz=zlib.
-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 The names after -h and -o are usually the same.
o -hnm is a linker option.
o -hnm facilitates versions for dynamic libraries.
See the Oracle Solaris 11.3 Linkers
and Libraries Guide.
-help
List the f95 command-line options.
See also: -xhelp.
-Ipath
Add path to the include file search path.
Insert directory path path at the start of the include file search
path. A space is allowed between -I and path.
The include file search path is the list of directories searched
for include files. This search path is used by:
o the preprocessor directive #include
o the f95 statement INCLUDE
Example: To search for include files in /usr/applib:
f95 -I/usr/applib growth.F
To invoke the preprocessor, you must be compiling source files with
.F, .F90, .F95, and .F03 suffixes.
The search path is also used to search for MODULE files.
The -Ipath search path is used while searching relative path names
on INCLUDE statements, not absolute path names. The search order
for relative path names is:
1. The directory containing the source file
2. Directory paths named in -I options
3. Directories in the default list of the compiler
4. /usr/include
-i8
(There is no -i8 option.)
Use -xtypemap=integer:64 to specify 8-byte INTEGER with this com‐
piler.
-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 opti‐
mizer decides which of these routines are appropriate for inlining.
A routine is not inlined if any of the following conditions apply,
with no warnings:
o Optimization is less than -O3.
o The routine cannot be found.
o Inlining it is not profitable or safe.
o The source is not in the file being compiled unless
-xipo is also specified.
-iorounding[={compatible | processor-defined}]
Set rounding mode for formatted input/output.
Sets the ROUND= specifier globally for all formatted input/output.
With -iorounding=compatible, the value resulting from data conver‐
sion 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 pro‐
cessor'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.
-keepmod[={yes|no}]
If a module file exists and its content is not changed by the lat‐
est compilation, it will not be replaced even though the compila‐
tion is supposed to create a new module file with the same name.
Since the content of the module file is unchanged by the compila‐
tion, the only effect is that the time stamp of the existing module
file will be preserved.
The default, when -keepmod is not specified, is -keepmod=yes. Note
that this default is different from previous releases of Oracle
Developer Studio Fortran.
This option is best used together with the dependencies generated
by the -xM compilation option. By retaining the time stamp of a
module file when its content is unchanged, this option prevents
cascading compilation for the source files depending on this module
file. This is very helpful in an incremental build and can signifi‐
cantly reduce the build time.
When this option is used with user-specified dependencies and the
user has an explicit build rule on how to create the module with a
dependency on the corresponding source file, the option can cause
the source file to be recompiled multiple times even though the
source file is modified only once because of the outdated time
stamp of the module file.
-keeptmp
Retains the temporary files that are created during compilation.
-Lpath
Add path to list of directory paths to search for libraries.
path is added to the start of the search list. A space between -L
and path is optional.
Note: Do not use the -Lpath option to specify /usr/lib or
/usr/ccs/lib, since they are searched by default, and including
them here prevents using the unbundled libm.
-lx
Add library libx.a to the linker's list of search libraries.
Direct the loader to link with object library libx.a, where x is a
string. See ld(1).
Example: -lsumex links in the library libsumex.a
Place -lx options after any .f, .F, or .o files. If you call func‐
tions in libx, and they reference functions in liby, then place -lx
before -ly.
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 com‐
piler. This option inlines library calls depending on the floating-
point options and platform currently being used.
-library=sunperf
Link with the Oracle Developer Studio supplied performance
libraries.
-loopinfo
Show which loops are parallelized.
Show which loops are parallelized and which are not. This option is
normally for use with the -autopar option. It generates a list of
messages on standard error.
-Mpath
Specify MODULE directory, archive, or file.
Look in path for Fortran 95 modules referenced in the current com‐
pilation. This path is searched in addition to the current direc‐
tory.
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 cur‐
rent directory. When both are specified, the write-directory is the
path specified by the -moddir flag.
This means that if only the -M flag appears, the current directory
will be searched for modules first before any object listed on the
-M flag. To emulate the behavior of previous releases, use:
-moddir=empty-dir -Mdir -M
where empty-dir is the path to an empty directory.
Directories named in -I path will be searched for module files if
the files are not found in any of the other locations that are
searched.
A space between the -M and the path is allowed. For example, -M
/home/siri/PK15/Modules.
On Oracle Solaris, if the path identifies a regular file that is
not an archive or a module file, the compiler passes the option to
the linker, ld, which will treat it as a linker mapfile. This fea‐
ture is provided as a convenience similar to the C and C++ compil‐
ers.
-m32 | -m64
Specify data type 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.
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 data type model, ILP32
or LP64, was implied by the choice of the instruction set with
-xarch. Starting with the Sun Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the command
line is sufficient to create 64-bit objects.
On Oracle Solaris systems, -m32 is the default. On Linux systems,
-m64 is the default.
See also: -xarch
-moddir=path
Specify the path to a directory where the compiler will write .mod
MODULE files. The path can also be specified by using the MODDIR
environment variable. If both are specified, this option flag takes
precedence.
The default directory for writing .mod files is the current direc‐
tory.
-mt[={yes|no}]
Use this option to compile and link multithreaded code.
This option passes -D_REENTRANT to the preprocessor.
-mt=yes is the default behavior of the compiler. -mt is equivalent
to -mt=yes. If this behavior is not desired use the option -mt=no.
The -xopenmp option (for using the OpenMP shared-memory paral‐
lelization API) includes -mt=yes automatically.
Use this option consistently. If you compile and link one transla‐
tion unit with -mt, you must compile and link all units of the pro‐
gram with -mt.
To determine which system support libraries will be linked by
default, compile with the -dryrun option.
See also: -xnolib
-native
Optimize for the host system.
The -native option is a synonym for the -xtarget=native option.
-noautopar
Cancel -autopar on the command line.
Cancel automatic parallelization of loops invoked by -autopar on
the command line.
-nodepend
Cancel -depend in command line.
Cancel dependence analysis invoked by a -depend option appearing
earlier in the command line.
-nofstore
(x86) Cancel -fstore on command line.
Cancels forcing expressions to have the precision of the destina‐
tion 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 stati‐
cally.
-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 nor‐
mally 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. Com‐
pare 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 bet‐
ter 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 rec‐
ommended 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 maxi‐
mum 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, and auto‐
matic inlining of functions whose body is smaller than the
overhead of calling the function. In general, this level,
and -O4,usually result in the minimum code size
when used with the -xspace option. Automatically turns on
-depend data dependence analysis.
-O4 Adds automatic inlining of functions in the same file. -O4
results in larger code unless combined with -xspace.
See -inline to control which routines are inlined.
-O5 Does the highest level of optimization, suitable only for
the small fraction of a program that uses the largest frac‐
tion 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 com‐
piler provides best-effort symbolic information with almost full
optimization. Tail-call optimization and back-end inlining are dis‐
abled.
For more information, see Oracle
Developer Studio 12.6: Debugging a Program with
dbx.
See also: -fast, -xprofile=p, csh(1) man page
-o filename
Names the output file filename, instead of the default a.out. file‐
name cannot be the same as sourcefile since cc does not overwrite
the source file.
filename must have an appropriate suffix. When used with -c, file‐
name specifies the target .o object file; with -G it specifies the
target .so library file. This option and its argument are passed to
ld.
-onetrip
Enable one-trip DO loops.
Compile DO loops so they are performed at least once if reached.
Fortran 95 DO loops are not performed at all if the upper limit is
smaller than the lower limit, unlike some legacy implementations of
Fortran.
-openmp
Synonym for -xopenmp.
-p
(Obsolete) Compile for profiling with prof.
Prepare object files for profiling with prof(1). This option makes
profiles by procedure, showing the number of calls to each proce‐
dure 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 equiva‐
lenced.
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 vari‐
ables 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 inconsis‐
tently with -pad=common will cause errors. Compiling with -Xlist
will report when common blocks with the same name have different
lengths in different program units.
-pg
Prepares the object code to collect data for profiling with
gprof(1). -xpg is a synonym for -pg.
Invokes a runtime recording mechanism that produces a gmon.out file
(at normal termination).
Note -
There is no advantage compiling with -xprofile if you specify
-xpg. The two do not prepare or use data provided by the other.
Profiles are generated by using prof or gprof on 64 bit Oracle
Solaris platforms or just gprof on 32 bit Oracle Solaris platforms
include approximate user CPU times. These times are derived from PC
sample data (see pcsample(2)) for routines in the main executable
and routines in shared libraries specified as linker arguments when
the executable is linked. Other shared libraries (libraries opened
after process startup using dlopen(3DL)) are not profiled.
On 32 bit Oracle Solaris systems, profiles generated using prof(1)
are limited to routines in the executable. 32 bit shared libraries
can be profiled by linking the executable with -xpg and using
gprof(1).
The latest Oracle Solaris releases do not include system libraries
compiled with -p. As a result, profiles collected on current Oracle
Solaris platforms do not include call counts for system library
routines.
Note: On x86 systems, -xpg is incompatible with -xregs=frameptr
because the gprof runtime library requires a valid frame pointer to
determine the return address of a profiled routine. Note also that
compiling with -fast on x86 systems will invoke -xregs=frameptr.
Compile with the following instead:
-fast -xregs=no%frameptr -xpg
Note: The compiler options -p, -pg, or -xpg should not be used to
compile multi-threaded programs, because the runtime support for
these options is not thread-safe. If a program that uses multiple
threads is compiled with these options invalid results or a segmen‐
tation fault could occur at runtime.
For separate compile and link steps, if you compile with -pg, then
link with -pg.
Warning: Binaries compiled with -xpg for gprof profiling should not
be used with binopt(1), as they are incompatible and can result in
internal errors.
-pic
Compile position-independent code for shared library.
On SPARC, -pic is equivalent to -xcode=pic13.
On x86, produces position-independent code. Use this option to com‐
pile 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, -PIC is equivalent to -xcode=pic32.
On x86, -PIC is identical to -pic.
-preserve_argvalues[=simple|none|complete]
(x86) Saves copies of register-based function arguments in the
stack.
When none is specified or if the -preserve_argvalues option is not
specified on the command line, the compiler behaves as usual.
When simple is specified, up to six integer arguments are saved.
When complete is specified, the values of all function arguments in
the stack trace are visible to the user in the proper order.
The values are not updated during the function lifetime on assign‐
ments to formal parameters.
-Qoption pr ls
Pass option list ls to the compilation phase pr.
This option is used primarily by customer service.
-qp
Synonym for -p.
-R list
Build library search paths into executable.
With this option, the linker, ld(1), adds a list of library search
paths into the executable file.
list is a colon-separated list of directories used to specify
library search paths to the runtime linker. The list is added to
the default list that f95 passes to the linker.
The blank between -R and list is optional.
Multiple instances of this option are concatenated together, with
each list separated by a colon.
Use this option if you want to export an executable that can run
without any special option for paths to your dynamic libraries.
Building an executable with this option adds paths to a default
path that is always searched last:
<installpath>/lib
The default library search order can be seen by using the -dryrun
option and examining the -Y option of the ld invocation.
-r8const
Promote single-precision constants to REAL*8 constants.
All single precision literal constants are promoted to REAL*8. Dou‐
ble-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 argu‐
ment where a REAL*4 value is expected. It could also cause problems
with programs reading unformatted data files written by a write
statement with a literal REAL*4 constant on its I/O list.
-recl=a[,b]
Set default output record length.
Set the default record length (in characters) for either or both
preconnected units output (standard output) and error (standard
error).
This option must be specified using one of the following forms:
-recl=out:N
-recl=error:N
-recl=out:N1,error:N2
-recl=error:N1,out:N2
-recl=all:N
where N, N1, N2 are all positive integers in the range from 72 to
2147483646.
out refers to standard output, error to standard error, and all
sets the default record length to both.
The default is -recl=all:80.
This option is only effective if the program being compiled has a
Fortran main program.
-reduction
Parallelize reduction operations in loops.
Analyze loops for reduction in automatic parallelization. To enable
parallelization of reduction loops, specify both -reduction and
-autopar.
Example: demo% f95 -autopar -reduction any.f
A loop that transforms the elements of an array into a single
scalar value is called a reduction operation. For example, summing
the elements of a vector is a typical reduction operation. Although
these operations violate the criteria for parallelization, the com‐
piler 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.
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.
-shared
Produces a shared object rather than a dynamically-linked exe‐
cutable. This option is passed to ld (as -G), and cannot be used
with the -dn option.
When you use the -shared option, the compiler passes default -l
options to ld, which are the same options that would be passed if
you created an executable.
If you are creating a shared object by specifying the -shared
option along with other compiler options that are specified at both
compile time and link time, make sure that that those options are
also specified when you link with the resulting shared object.
When you create a shared object, all the object files that are com‐
piled for 64-bit SPARC architectures must also be compiled with an
explicit -xcode value as documented under the description of
-xcode.
For more information, see the -G option.
-silent
Suppress compiler messages.
Normally, f95 does not issue messages, other than error diagnos‐
tics, during compilation. This option is provided only for compati‐
bility 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.
-stackvar recommended for use with the -autopar option. -stackvar
is automatically turned on with the -xopenmp, -xopenmp=parallel,
and -xopenmp=noopt options. 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 state‐
ment, such as:
REAL X/8.0/ or DATA X/8.0/
Putting large arrays onto the stack with -stackvar can overflow the
stack causing segmentation faults. Increasing the stack size might
be required.
The initial thread executing the program has a main stack, while
each helper thread of a multithreaded program has its own thread
stack.
The default size for the main stack is about 8 Megabytes. The
default helper thread stack size is 4 Megabytes on 32-bit platforms
and 8 Megabytes on 64-bit platforms.
The limit command (with no parameters) shows the current main stack
size.
Use the limit shell command to set the size (in Kilobytes) of the
main thread stack. For example, to set the main stack size to 64
Megabytes, use this command:
% limit stacksize 65536
You can set the stack size to be used by each slave thread by giv‐
ing the STACKSIZE environment variable a value (in Kilobytes):
% setenv STACKSIZE 8192
This 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 over‐
flow situations.
-stop_status[={yes|no}]
Enable the STOP statement to return an integer status value.
The optional argument is either yes or no. The default is yes.
With -stop_status=yes a STOP statement can contain an integer con‐
stant that will be passed to the environment as the program termi‐
nates. This value will be available as $status for the C shell or
$? for the Bourne and Korn shells.
The value on the STOP statement can be any positive integer. The
value returned to the shell will be modulo 256 (in the range 0 to
255).
-temp=dir
Define directory for temporary files.
Set the directory for temporary files used by f95 to be dir instead
of the /tmp directory. This option has precedence over the TMPDIR
environment variable.
-time
Show execution time for each compilation phase.
-traceback[={%none|common|signals_list}]
Issue a stack trace if a severe error occurs in execution.
The -traceback option causes the executable to issue a stack trace
to stderr, dump core, and exit if certain signals are generated by
the program. If multiple threads generate a signal, a stack trace
will only be produced for the first one.
To use traceback, add the -traceback option to the compiler command
line when linking. The option is also accepted at compile-time but
is ignored unless an executable binary is generated. Using -trace‐
back with -G to create a shared library is an error.
%none
none
Disables traceback.
common
Specifies that a stack trace should be issued if any of a set
of common signals is generated: sigill, sigfpe, sigbus,
sigsegv, and sigabrt.
signals_list
Specifies a comma-separated list of names of signals which
should generate a stack trace, in lower case. The following
signals (those that cause the generation of a core file) can be
caught: sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe, sig‐
bus, sigsegv, sigsys, sigxcpu, and sigxfsz.
Any of these can be preceeded with no% to disable catching the
signal.
For example: -traceback=sigsegv,sigfpe will produce a stack
trace and core dump if either sigsegv or sigfpe is generated.
If the option is not specified, the default is -traceback=%none.
-traceback without any = sign implies -traceback=common.
Note: If the core dump is not wanted, users may set the coredump‐
size limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
-U
Recognize upper and lower case in source files.
Do not treat uppercase letters as equivalent to lowercase. The
default is to treat uppercase as lowercase except within character-
string constants.
With this option, the compiler treats Delta, DELTA, and delta as
different symbols.
Portability and mixing Fortran with other languages might require
use of -U.
Calls to intrinsic functions are not affected by this option.
-Uname
Undefine preprocessor macro name.
Removes any initial definition of the preprocessor macro symbol
name created by -Dname on the same command line, or implicitly
placed there by the command-line driver, regardless of the order
the options appear. It has no affect on any macro definitions in
source files. Multiple -Uname flags may appear on the same line,
and there must be no space between -U and name.
This option applies only to .F, .F90, .F95, and .F03 source files
that invoke the fpp or cpp preprocessors.
-u
Report on undeclared variables.
Equivalent to specifying IMPLICIT NONE in each compilation unit.
This has the affect of making the default type of variables unde‐
clared 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 > 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=mod‐
ule_name in effect adds a USE module_name to each subprogram being
compiled. Similarly, compiling with -use=module_file_name effec‐
tively 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 sub-options 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 For‐
tran, 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 preced‐
ing with no%).
Example:
-vax=debug,rsize,no%blank_zero
The default is -vax=%none. If -vax is specified without any sub-
options, it is equivalent to -vax=%all.
-vpara
Show parallelization warning messages.
Issues warnings about potential parallel programming related prob‐
lems that may cause incorrect results with with -xopenmp and OpenMP
API directives.
Warnings are issued when the compiler detects a problematic use of
OpenMP data sharing attributes clauses, such as declaring a vari‐
able "shared" whose accesses in an OpenMP parallel region may cause
data race, or declaring a variable "private" whose value in a par‐
allel region is used after the parallel region.
No warnings appear if all parallelization directives are processed
without issues.
For example, f95 -xopenmp -vpara any.f
-Wc,arg
Passes the argument arg to component c. Each argument must be sepa‐
rated from the preceding by only a comma. (A comma can be part of
an argument by escaping it by an immediately preceding backslash
(\) character; the backslash is removed from the resulting argu‐
ment.) All -W arguments are passed after the regular command-line
arguments.
c can be one of the following:
a Assembler: (fbe), (gas)
c f95 code generator: (cg)(SPARC)
d f95 driver
l Link editor (ld)
m mcs
O (Capital letter 'O') Interprocedural optimizer
o Postoptimizer
p Preprocessor (fpp or cpp)
0 (The number zero) Compiler (f90comp)
2 Optimizer: (iropt)
3 Static error checking: (previse)
Note: You cannot use -Wd to pass the f95 options listed in this man
page to the Fortran compiler.
For example, -Wa,-o,objfile passes -o and objfile to the assembler,
in that order; also -Wl,-I,name causes the linking phase to over‐
ride the default name of the dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool with
respect to the other specified command line options may change.
-w[{0|1|2|3|4}]
Show or suppress warning messages.
-w suppresses warning messages from the compiler.
-w0 shows just error messages.
-w1 shows errors and warnings. (This is the default.)
-w2 shows errors, warnings, and cautions.
-w3 shows errors, warnings, cautions, and notes.
-w4 shows errors, warnings, cautions, notes, and comments.
If you specify two options, and the second one overrides all or
part of the first one, the compiler issues a warning.
-Xlinker arg
Pass arg to the linker, ld.
-Xlist[z]
(Obsolete) This option is obsolete and might be removed in a future
release.
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 pro‐
gram. Generates line-numbered source code listing with cross refer‐
ences.
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 Sub-options
-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 Outpnumt to nm instead of to file.lst
-Xlists Suppress unreferenced names from cross-refer‐
ence table.
-Xlistvn Set checking level to n (1,2,3, or 4) - default
is 2
-Xlistw[nnn] Set output line width to n; default is 79
-Xlistwar Suppress all -Xlist warning messages
-Xlistwar[n] Suppress -Xlist warning message n.
-XlistX Cross-reference only (no listings)
See the Fortran Programming Guide for details.
-xaddr32[={yes|no}]
(x86/x64) 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 cre‐
ation of a process that is restricted to a 32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is produced.
If the -xaddr32 option is not specified, -xaddr32=no is assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and only on
Oracle Solaris platforms supporting SF1_SUNW_ADDR32 software capa‐
bility.
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 capabil‐
ities definition, described in the Oracle Solaris 11.3 Linkers 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 particu‐
lar, 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 Oracle Developer Studio
12.6: Fortran User' 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 stan‐
dard 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 reference to an element of an array in a COMMON block could
refer to any element in a COMMON block or equivalence group.
Passing any element of a COMMON block or equivalence group as
an actual argument to a subprogram gives access to any element
of that COMMON block or equivalence group to the called subpro‐
gram. Elements of a sequence-derived type are treated as if
they were COMMON blocks. Individual array bounds may be vio‐
lated, 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 cor‐
responds to:
-xalias=no%dummy,no%craypointer,no%actual,no%overindex,\
no%ftnpointer
To be effective, -xalias should be used when compiling with opti‐
mization levels -xO3 and higher.
See the chapter on Porting in the Fortran Programming
Guide for further details.
-xannotate[={yes|no}]
Instructs the compiler to create binaries that can later be used by
the optimization and observability tools binopt(1), code-ana‐
lyzer(1), discover(1), collect(1), and uncover(1).
The default on Oracle Solaris is -xannotate=yes. The default on
Linux is -xannotate=no. Specifying -xannotate without a value is
equivalent to -xannotate=yes.
For optimal use of the optimization and observability tools, -xan‐
notate=yes must be in effect at both compile and link time.
Compile and link with -xannotate=no to produce slightly smaller
binaries and libraries when optimization and observability tools
will not be used.
-xarch=isa
Specifies the target architecture instruction set (ISA).
This option limits the code generated by the compiler to the
instructions of the specified instruction set architecture by
allowing only the specified set of instructions. This option does
not guarantee use of any target-specific instructions. However, use
of this option can affect the portability of a binary program. See
the Notes and Warnings sections at the end of this entry.
Note: The compiler and linker will mark .o files and executables
that require a particular instruction set architecture (ISA) so
that the executable will not be loaded at runtime if the running
system does not support that particular ISA.
Note: Use the -m64 or -m32 option to specify the intended data type
model, LP64 (64-bits) or ILP32 (32-bits) respectively. The -xarch
flag no longer indicates the data type model, except for compati‐
bility with previous releases, as indicated below.
If you compile and link in separate steps, make sure you specify
the same value for -xarch in both steps.
Values for all platforms:
generic
This option uses the instruction set common to most processors.
This is the default and is equivalent to -xarch=sse2 on x86
platforms and -xarch=sparcvis2 on SPARC platforms.
native
Compile for good performance on this system.
The compiler chooses the appropriate setting for the current
system processor it is running on.
Values specific to SPARC platforms:
sparc
Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual Instruction Set
(VIS), and without other implementation-specific ISA exten‐
sions. This option enables the compiler to generate code for
good performance on the V9 ISA.
sparc4
Compile for the SPARC4 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the UltraSPARC extensions, which includes
VIS 1.0, the UltraSPARC-III extensions, which includes VIS2.0,
the fused floating-point multiply-add instructions, VIS 3.0,
and SPARC4 instructions.
sparc4b
Compile for the SPARC4B version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the UltraSPARC extensions, which includes
VIS 1.0, the UltraSPARC-III extensions, which includes VIS2.0,
the SPARC64 VI extensions for floating-point multiply-add, the
SPARC64 VII extensions for integer multiply-add, and the PAUSE
and CBCOND instructions from the SPARC T4 extensions.
sparc4c
Compile for the SPARC4C version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the UltraSPARC extensions, which includes
VIS 1.0, the UltraSPARC-III extensions, which includes VIS2.0,
the SPARC64 VI extensions for floating-point multiply-add, the
SPARC64 VII extensions for integer multiply-add, the VIS3B sub‐
set of the VIS 3.0 instructions a subset of the SPARC T3 exten‐
sions, called the VIS3B subset of VIS 3.0, and the PAUSE and
CBCOND instructions from the SPARC T4 extensions.
sparc5
Compile for the SPARC5 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the extensions, which includes VIS 1.0,
the Ultra SPARC-III extensions, which includes VIS2.0, the
fused floating-point multiply-add instructions, VIS 3.0,
SPARC4, and SPARC5 instructions.
sparcace
Compile for the sparcace 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,
the SPARC64 VII extensions for integer multiply-add, and the
SPARC64 X extensions for SPARCACE floating-point.
sparcaceplus
Compile for the sparcaceplus 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,
the SPARC64 VII extensions for integer multiply-add, the
SPARC64 X extensions for SPARCACE floating-point, and the
SPARC64 X+ extensions for SPARCACE floating-point.
sparcace2
Compile for the sparcace2 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,
the SPARC64 VII extensions for integer multiply-add, the
SPARC64 X extensions for SPARCACE floating-point, the SPARC64
X+ extensions for SPARCACE floating-point, and the SPARC64 XII
extensions for SPARCACE floating-point.
sparcvis
Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set (VIS) ver‐
sion 1.0, and with UltraSPARC extensions. This option enables
the compiler to generate code for good performance on the
UltraSPARC architecture.
sparcvis2
Compile for the SPARC-V9 ISA with UltraSPARC III extensions.
Enables the compiler to generate object code for the UltraSPARC
architecture, plus the Visual Instruction Set (VIS) version
2.0, and with UltraSPARC III extensions.
sparcvis3
Compile for the SPARC-V9 ISA with UltraSPARC III and VIS 3
extensions.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, the fused multiply-add instructions, and the Visual
Instruction Set (VIS) version 3.1
sparcfmaf
Compile for the sparcfmaf version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9
instruction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, and the SPARC64 VI extensions for floating-point multiply-
add.
Note that you must use -xarch=sparcfmaf in conjunction with
-fma=fused and some optimization level to get the compiler to
attempt to find opportunities to use the multiply-add instruc‐
tions 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 data type model need
only use -m64.
v9a
Is equivalent to -m64 -xarch=sparcvis and is provided for com‐
patibility with earlier releases.
v9b
Is equivalent to -m64 -xarch=sparcvis2 and is provided for com‐
patibility with earlier releases.
Object binary files (.o) compiled with sparc and sparcvis can be
linked and can execute together, but only on a sparcvis compatible
platform.
Object binary files (.o) compiled with sparc, sparcvis, and spar‐
cvis2 can be linked and can execute together, but only on a spar‐
cvis2 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 instruc‐
tion set architectures, the compiler does not use these instruc‐
tions in the code it generates.
Values specific to x86 platforms:
avx512
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, PCLMULQDQ, AVX, FSGSBASE, RDRND, F16C, AVX2, BMI1,
BMI2, LZCNT, INVPCID, FMA, ADX, RDSEED, PREFETCHW, PREFETCHWT1,
AVX512F, AVX512CDI, AVX512VLI, AVX512BW and AVX512DQ instruc‐
tions.
avx2_i
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, PCLMULQDQ, AVX, FSGSBASE, RDRND, F16C, AVX2, BMI1,
BMI2, LZCNT, INVPCID, FMA, ADX, RDSEED, PREFETCHW and
PREFETCHWT1 instructions.
avx2
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, PCLMULQDQ, AVX, FSGSBASE, RDRND, F16C, AVX2, BMI1,
BMI2, LZCNT, INVPCID, and FMA instructions.
avx_i
May use 386, pentium_pro, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, PCLMULQDQ, FSGSBASE, RDRND, and F16C instructions.
avx
May use 386, pentium_pro, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, and PCLMULQDQ instructions.
aes
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AES, and PCLMULQDQ instructions.
sse4_2
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1,
and SSE4.2 instructions.
sse4_1
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, and
SSE4.1 instructions.
ssse3
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, and SSSE3
instructions.
sse3
May use 386, MMX, Pentium_pro, SSE, SSE2, and SSE3 instruc‐
tions.
amdsse4a
Uses the AMD SSE4a Instruction set.
sse2
May use 386, MMX, Pentium_pro, SSE, and SSE2 instructions.
sse2a
May use 386, MMX, Pentium_pro, SSE, SSE2 and AMD extension:
3DNow!, 3DNow! extension instructions for AMD processors.
sse
(Obsolete) Use -xarch-generic instead.
ssea
May use 386, MMX, Pentium_pro, SEE and AMD extension: 3DNow!,
3DNow! extension instructions for AMD processors.
pentium_pro
(Obsolete) Use -xarch-generic instead.
pentium_proa
May use 386, MMX, Pentium_pro and AMD extension: 3DNow!, 3DNow!
extensions instructions for AMD processors.
generic
Uses the instruction set common to most processor.
native
Uses the instructions available on the current system processor
the compiler is running on.
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.
Defaults:
If -xarch=isa is not specified, the defaults are: -xarch=generic on
SPARC platforms and -xarch=generic on x86/x64 platforms.
Interactions:
Although this option can be used alone, it is part of the expansion
of the -xtarget option and can be used to override the -xarch value
that is set by a specific -xtarget option. For example,
-xtarget=T3
expands to
-xarch=sparcvis3 -xcache=8/16/4:6144/64/24 -xchip=T3
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 prag‐
mas in the source code.
See the Oracle Developer Studio
12.6: Fortran User' Guide for descriptions of the
ASSUME pragmas.
The ASSUME pragmas provide a way for the programmer to assert spe‐
cial 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 sub-options 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 asser‐
tion 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". retro‐
spective 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 -xas‐
sume_control=optimize. This means that the compiler recognizes
ASSUME pragmas and they will affect optimization, but no checking
is performed.
If specified without parameters, -xassume_control implies -xas‐
sume_control=check,fatal. In this case the compiler accepts and
checks all certain ASSUME pragmas, but they do not affect opti‐
mization. Assertions that are invalid cause the program to termi‐
nate.
-xautopar
Synonym for -autopar.
-xcache=c
Define cache properties for use by optimizer.
c must be one of the following:
o generic
o native
o s1/l1/a1[/t1]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, are defined as follows:
si The size of the data cache at level i, in kilobytes
li The line size of the data cache at level i, in bytes
ai The associativity of the data cache at level i
ti The number of hardware threads sharing the cache at
level i The ti parameters are optional. A value of 1
is used if not present.
This option specifies the cache properties that the optimizer can
use. It does not guarantee that any particular cache property is
used.
Although this option can be used alone, it is part of the expansion
of the -xtarget option; its primary use is to override a value sup‐
plied by the -xtarget option.
The -xcache values are:
generic
Define the cache properties for good performance on most plat‐
forms. This is the default.
native
Define the cache properties for good performance on this host
platform.
s1/l1/a1[/t1]
Define level 1 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]
Define levels 1 and 2 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
Define levels 1, 2, and 3 cache properties.
-xcheck[=n]
Performs a runtime check for stack overflow of the main thread in a
singly-threaded program as well as slave-thread stacks in a multi‐
threaded program. If a stack overflow is detected, a SIGSEGV is
generated. If your application needs to handle a SIGSEGV caused by
a stack overflow differently than it handles other address-space
violations, see sigaltstack(2).
n must be one of the following values.
%all
Perform all -xcheck checks.
%none
Do not perform any of the -xcheck checks.
stkovf[action]
Generate code to detect stack overflow errors at runtime,
optionally specifying an action to be taken when a stack over‐
flow error is detected.
A stack overflow error occurs when a thread's stack pointer is
set beyond the thread's allocated stack bounds. The error may
not be detected if the new top of stack address is writable.
A stack overflow error is detected if a memory access violation
occurs as a direct result of the error, raising an associated
signal (usually SIGSEGV). The signal thus raised is said to be
associated with the error.
An undetected stack overflow error may result in silent data
corruption. Preventing undetected stack overflow errors
requires compiler and runtime support.
If -xcheck=stkovf[action] is specified, the compiler generates
code to detect stack overflow errors in cases involving stack
frames larger than the system page size. The code includes a
library call to force a memory access violation instead of set‐
ting the stack pointer to an invalid but potentially mapped
address (see _stack_grow(3C)).
The optional action, if specified, must be one of the follow‐
ing:
:detect
If action is :detect, a detected stack overflow error is
handled by executing the signal handler normally associated
with the error.
On SPARC Solaris, -xcheck=stkovf:detect is enabled by
default. This prevents silent corruption of the stack due
to stack overflow. It can be disabled by specifying
-xcheck=no%stkovf.
:diagnose
If action is :diagnose, a detected stack overflow error is
handled by catching the associated signal and calling
stack_violation(3C) to diagnose the error. This is the
default behavior if no action is specified.
If a memory access violation is diagnosed as a stack over‐
flow error, the following message is printed to stderr:
ERROR: stack overflow detected:
pc=<inst_addr>, sp=<sp_addr>
where <inst_addr> is the address of the instruction where
the error was detected, and <sp_addr> is the value of the
stack pointer at the time that the error was detected.
After checking for stack overflow and printing the above
message if appropriate, control passes to the signal han‐
dler normally associated with the error.
-xcheck=stkovf:detect adds a stack bounds check on entry to
routines with stack frames larger than system page size (see
_stack_grow(3C)). The relative cost of the additional bounds
check should be negligible in most applications.
-xcheck=stkovf:diagnose adds a system call to thread creation
(see sigaltstack(2)). The relative cost of the additional sys‐
tem call depends on how frequently the application creates and
destroys new threads.
-xcheck=stkovf is supported only on Oracle Solaris. The C run‐
time library on Linux does not support stack overflow detec‐
tion.
no%stkovf
Turns off stack-overflow checking.
init_local
Perform special initialization of local variables.
With this option the compiler initializes local variables to a
value that is likely to cause an arithmetic exception if it is
used before it is assigned by the program. Memory allocated by
the ALLOCATE statement will also be initialized in this manner.
Module variables, STATIC and SAVE local variables, and vari‐
ables in COMMON blocks are not initialized.
See the Oracle Developer
Studio 12.6: C User's Guide description
of this option for a list of the predefined values used by the
compiler to initialize variables.
Exercise caution when using -xcheck with a large amount of
local data, such as arrays with more than 10,000 elements. This
can cause the compiler's internal representation of the program
to become very large when that local date is initialized, which
can result in significantly longer compilation times, espe‐
cially when combined with optimization levels greater than -02.
no%init_local
Do not initialize local variables.
If you do not specify -xcheck, the compiler defaults to
-xcheck=%none and if you specify -xcheck without any arguments, the
compiler defaults to -xcheck=%all, unless you are on an Oracle
Solaris system for SPARC, in which case, the compiler will default
to -xcheck=stkovf:detect for both cases.
The -xcheck option does not accumulate on the command line. The
compiler sets the flag in accordance with the last occurrence of
the command.
-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 sup‐
plied 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 (Obsolete)
Optimize for the SPARC64 VI processor.
sparc64vii (Obsolete)
Optimize for the SPARC64 VII processor.
sparc64viiplus
Optimize for the SPARC64 VII+ processor.
sparc64x
Optimize for the SPARC64 X processor.
sparc64xplus
Optimize for the SPARC64 X+ processor.
sparc64xii
Optimize for the SPARC64 XII processor.
ultraT1 (Obsolete)
Optimize for the UltraSPARC T1 chip.
ultraT2 (Obsolete)
Optimize for the UltraSPARC T2 chip.
ultraT2plus (Obsolete)
Optimize for the UltraSPARC T2+ chip.
T3 (Obsolete)
Optimize for the SPARC T3 chip.
T4
Optimize for the SPARC T4 chip.
T5
Optimize for the SPARC T5 processor.
T7
Optimize for the SPARC T7 processor.
M5
Optimize for the SPARC M5 processor.
M6
Optimize for the SPARC M6 processor.
M7
Optimize for the SPARC M7 processor.
generic
Optimize for good performance on most supported SPARC plat‐
forms. (This is the compiler default.)
native
Optimize for good performance on this host platform.
The -xchip values on x86 platforms are:
skylake
Optimize for the Intel Skylake processor.
broadwell
Optimize for Intel Broadwell processors.
nehalem
Optimize for Intel Nahelem processors.
core2
Optimize for Intel Core2 processors.
amdfam10
Obsolete. Use -xchip=generic instead.
penryn
Optimize for Intel Pentryn processors.
sandybridge
Optimize for Intel Sandy Bridge processors.
ivybridge
Optimize for the Intel Ivy Bridge processor.
haswell
Optimize for the Intel Haswell processor.
westmere
Optimize for Intel Westmere processors.
opteron
Optimize for AMD Opteron processors.
pentium
(Obsolete) Use -xchip=generic instead.
pentium_pro
(Obsolete) Use -xchip=generic instead.
pentium3
(Obsolete) Use -xchip=generic instead.
pentium4
Optimize for Pentium 4 processors.
generic
Optimize for most x86 platforms.
native
Optimize for this host processor.
For complete information, see the Oracle Developer Studio 12.6:
Fortran User' Guide.
-xcode=v
(SPARC) Specify code address space.
Note: It is highly recommended that you build shared objects by
specifying -xcode=pic13 or -xcode=pic32. It is possible to build
workable shared objects with -m64 -xcode=abs64, but these will be
inefficient. Shared objects built with -m64 xarch=v9 -xcode=abs32
or -m64 -xcode=abs44 will not work.
The values for -xcode are:
abs32
This is the default for 32-bit systems. Generates 32-bit abso‐
lute addresses. Code + data + bss size is limited to 2**32
bytes.
abs44
This is the default for 64-bit systems. Generates 44-bit abso‐
lute addresses. Code + data + bss size is limited to 2**44
bytes. Available only on 64-bit architectures.
abs64
Generates 64-bit absolute addresses. Available only on 64-bit
architectures.
pic13
Generates position-independent code for use in shared libraries
(small model). Equivalent to -Kpic. Permits references to at
most 2**11 unique external symbols on 32-bit architectures,
2**10 on 64-bit.
pic32
Generates position-independent code for use in shared libraries
(large model). Equivalent to -KPIC. 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 architectures. The default
is -xcode=abs44 for 64-bit architectures.
When building shared dynamic libraries, the default -xcode value of
abs44 (not abs32) will not work with 64-bit architectures. Specify
-xcode=pic13 or -xcode=pic32 instead.
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 to look for the sec‐
tion 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 exceeds 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.
-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 declara‐
tions 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.
-xcompress={[no%]debug}
Compresses debug sections using the format specified by the -xcom‐
press_format option if supported by the underlying Operating Sys‐
tem. A sub-option is required. The option is ignored with a warning
when Operating System support is unavailable.
-xcompress_format=cmp-type
When -xcompress=debug is in effect, this options specifies how the
debug section is to be compressed.
The following values for cmp-type are recognized:
none No compression of the debug section is done.
zlib Compresses the debug section using ZLIB compression.
zlib-gnu Compresses the section using ZLIB compression, using
the GNU section compression format.
On Oracle Solaris, when compilation involves linking, the debug
sections are compressed using the ld option -z compress-sec‐
tions=cmp-type. For more information, see the ld(1) man page.
On Oracle Solaris, when compiling to an object file (.o), the debug
sections are compressed using elfcompress -t cmp-type. For more
information, see the elfcompress(1) man page.
On Linux, the objcopy command is used to compress debug sections of
each .o file using the objcopy --compress-debug-sections. For more
information, see the objcopy(1g) man page.
The option is ignored with a warning when Operating System support
is unavailable.
-xdebugformat=dwarf
-xdebugformat=dwarf generates debugging information using the
dwarf standard format. This is the default. The option is obsolete.
Notes:
The detailed format of individual fields in dwarf format may evolve
over time.
See also the man page for dwarfdump(1).
-xdebuginfo=a[,a...]
Control how much debugging and observability information is emit‐
ted.
The term tagtype refers to tagged types: structs, unions, enums,
and classes.
The following list contains the possible values for sub-options a.
The prefix no% applied to a sub-option disables that sub-option.
The default is -xdebuginfo=%none. Specifying -xdebuginfo without a
sub-option is forbidden.
%none
No debugging information is generated. This is the default.
[no%]line
Emit line number and file information.
[no%]param
Emit location list info for parameters. Emit full type informa‐
tion for scalar values (for example, int, char *) and type
names but not full definitions of tagtypes.
[no%]variable
Emit location list information for lexically global and local
variables, including file and function statics but excluding
class statics and externs. Emit full type information for
scalar values such as int and char * and type names but not
full definitions of tagtypes.
[no%]decl
Emit information for function and variable declarations, member
functions, and static data members in class declarations.
[no%]tagtype
Emit full type definitions of tagtypes referenced from param
and variable datasets, as well as template definitions.
[no%]macro
Emit macro information.
[no%]codetag
Emit DWARF codetags (also known as Stabs N_PATCH). This is
information regarding bitfields, structure copy, and spills
used by RTC and discover.
[no%]hwcprof
Generate information critical to hardware counter profiling.
This information includes ldst_map, a mapping from ld/st
instructions to the symbol table entry being referenced, and
branch_target table of branch-target addresses used to verify
that backtracking did not cross a branch-target. See -xhwcprof
for more information.
Note: ldst_map requires the presence of tagtype information. The
driver will issue an error if this requirement is not met.
These are macros which expand to combinations of -xdebuginfo and
other options as follows:
-g = -g2
-gnone =
-xdebuginfo=%none
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g1 =
-xdebuginfo=line,param,codetag
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g2 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
-g3 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag,macro
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
-xdepend
Synonym for -depend.
-xdryrun
Synonym for -dryrun.
-xF
Allow function-level reordering by the Oracle Developer Studio Per‐
formance 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 depend‐
ing 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 appli‐
cation text page fault time is consuming a large percentage of the
application time. Otherwise, reordering might not improve the over‐
all performance of the application. The Performance Analyzer is
part of Oracle Developer Studio. See the Oracle Developer Studio
12.6: Performance Analyzer manual for further information on the
analyzer.
-xfilebyteorder=options
Support file sharing between little-endian and big-endian plat‐
forms.
The flag identifies the byte-order and byte-alignment of unformat‐
ted I/O files. options must specify any combination of the follow‐
ing, 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 plat‐
form. 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 max‐
imum 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 pro‐
gram.
filename refers to a specific Fortran file name opened by the pro‐
gram.
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 com‐
mand 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 specifica‐
tions.
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=inte‐
ger:64,real:64,double:128 cannot be read by an x86 executable com‐
piled with -xtypemap=integer:64,real:64,double:64, since the
default double precision data types will have different sizes.
Note that with this release, Oracle Developer Studio sotware now
supports REAL*16 data on x86 platforms. Unformatted files contain‐
ing 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.
-xglobalize[={yes|no}]
Control globalization of function-level or file-level static vari‐
ables.
Globalization is a technique needed by fix and continue functional‐
ity in the debugger whereby function-level or file-level static
symbols are promoted to globals while a prefix is added to the name
to keep identically named symbols distinct.
The default is -xglobalize=no. Specifying -xglobalize is equivalent
to specifying -xglobalize=yes.
Interactions:
See -xpatchpadding.
-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. Com‐
pile routines calling subprograms with Hollerith constants with
-xhasc=no if the called subprogram expects that argument as INTEGER
or any other type other than CHARACTER.
-xhelp=flages
Show summary of compiler options.
-xhelp=flags is a synonym for -help.
-xhwcprof[={enable|disable}]
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 applica‐
tion's object files.
If you are compiling and linking in separate steps, use -xhwcprof
at link time as well.
An instance of -xhwcprof=enable or -xhwcprof=disable overrides all
previous instances of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof without any
arguments is the equivalent to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on and that the
debug data format be set to dwarf (-xdebugformat=dwarf), which is
now the default with this release of the Oracle Developer Studio
compilers.
-xhwcprof uses -xdebuginfo to automatically enable the minimum
amount of debugging information it needs, so -g is not required.
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.
-xhwcprof is implemented as a macro that expands to various other,
more primitive, options as follows:.
-xhwcprof
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=enable
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=disable
-xdebuginfo=no%hwcprof,no%tagtype,no%line
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
Oracle Developer Studio 12.6: Performance
Analyzer.
-xinline=rl
Synonym for -inline=rl.
-xinline_param=a[,a[,a]...]
Use this option to manually change the heuristics used by the com‐
piler for deciding when to inline a function call.
This option only has an effect at -O3 or higher. The following sub-
options have an effect only at -O4 or higher when automatic inlin‐
ing is on.
In the following sub-options n must be a positive integer; a can be
one of the following:
default
Set the values of all the sub-options to their default values.
max_inst_hard[:n]
Automatic inlining only considers functions smaller than n
pseudo instructions (counted in compiler's internal representa‐
tion) as possible inline candidates.
Under no circumstances will a function larger than this be con‐
sidered for inlining.
max_inst_soft[:n]
Set inlined function's size limit to n pseudo instructions
(counted in compiler's internal representation).
Functions of greater size than this may sometimes be inlined.
When interacting with max_inst_hard, the value of max_inst_soft
should be equal to or smaller than the value of max_inst_hard,
i.e, max_inst_soft <= max_inst_hard.
In general, the compiler's automatic inliner only inlines calls
whose called function's size is smaller than the value of
max_inst_soft. In some cases a function may be inlined when its
size is larger than the value of max_inst_soft but smaller than
that of max_inst_hard. An example of this would be if the
parameters passed into a function were constants.
When deciding whether to change the value of max_inst_hard or
max_inst_soft for inlining one specific call site to a func‐
tion, use -xinline_report=2 to report detailed inlining message
and follow the suggestion in the inlining message.
max_function_inst[:n]
Allow functions to increase due to automatic inlining by up to
n pseudo instructions (counted in compiler's internal represen‐
tation).
max_growth[:n]
The automatic inliner is allowed to increase the size of the
program by up to n% where the size is measured in pseudo
instructions.
min_counter[:n]
The minimum call site frequency counter as measured by profil‐
ing feedback (-xprofile) in order to consider a function for
automatic inlining.
This option is valid only when the application is compiled with
profiling feedback (-xprofile=use).
level[:n]
Use this sub-option to control the degree of automatic inlining
that is applied. The compiler will inline more functions with
higher settings for -xinline_param=level.
n must be one of 1, 2, or 3.
The default value of n is 2 when this option is not specified,
or when the options is specified without :n.
Specify the level of automatic inline
level:1 basic inlining
level:2 medium inlining (default)
level:3 aggressive inlining
The level decides the specified values for the combination of
the following inlining parameters:
max_growth
+ max_function_inst
+ max_inst
+ max_inst_call
When level = 1, all the parameters are half the values of the
default. When level = 2, all the parameters are the default
value. When level = 3, all the parameters are double the values
of the default.
max_recursive_depth[:n]
When a function calls itself either directly or indirectly, it
is said to be making a recursive call.
This sub-option allows a recursive call to be automatically
inlined up to n levels.
max_recursive_inst[:n]
Specifies the maximum number of pseudo instructions (counted in
compiler's internal representation) the caller of a recursive
function can grow to by performing automatic recursive inlin‐
ing.
When interactions between max_recursive_inst and max_recur‐
sive_depth occur, recursive function calls will be inlined
until either the max_recursive_depth number of recursive calls,
or until the size of the function being inlined into exceeds
max_recursive_inst. The settings of these two parameters con‐
trol the degree of inlining of small recursive functions.
If -xinline_param=default is specified, the compiler will set all
the values of the sub-opitons to the default values.
If the option is not specified, the default is -xin‐
line_param=default.
The list of values and options accumulate from left to right. So
for a specification of -xin‐
line_param=max_inst_hard:30,..,max_inst_hard:50, the value
max_inst_hard:50 will be passed to the compiler.
If multiple -xinline_param options are specified on the command
line, the list of sub-options likewise accumulate from left to
right. For example, the effect of
-xinline_param=max_inst_hard:50,min_counter:70 ...
-xinline_param=max_growth:100,max_inst_hard:100
will be the same as that of
-xinline_param=max_inst_hard:100,min_counter:70,max_growth:100
-xinline_report[=n]
This option generates a report written to standard output on the
inlining of functions by the compiler. The type of report depends
on the value of n, which must be 0, 1, or 2.
0 No report is generated.
1 A summary report of default values of inlining parame‐
ters is generated.
2 A detailed report of inlining messages is generated,
showing which callsites are inlined and which are not,
with a short reason for not inlining a callsite. In
some cases, this report will include suggested values
for -xinline_param that can be used to inline a call‐
site that is not inlined.
When -xinline_report is not specified, the default value for n is
0. When -xinline_report is specified without =n, the default value
is 1.
When -xlinkopt is present, the inlining messages about the call‐
sites that are not inlined might not be accurate.
The report is limited to inlining performed by the compiler that is
subject to the heuristics controllable by the -xinline_param
option. Callsites inlined by the compiler for other reasons may not
be reported.
-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 -xin‐
strument=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.
Interactions:
-xinstrument cannot be used together with -xlinkopt.
-xipo[={1|0|2}]
Perform interprocedural optimizations.
Invoke interprocedural analysis pass to perform whole-program opti‐
mizations. -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 anal‐
ysis, 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 func‐
tions or subroutines compiled without -xipo=2 (for example, from
libraries) to functions or subroutines compiled with -xipo=2. Oth‐
erwise, 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 cross‐
file interprocedural analysis. Also, .s assembly language source
files do not participate in the analysis.
The -xipo flag is ignored if compiling with -S.
The -xipo flag requires at least optimization level -xO4.
Building executables compiled with -xipo using a parallel make tool
can cause problems if object files used in the build are common to
the link steps running in parallel. Each link step should have its
own copy of the object file being optimized prior to linking.
Objects compiled without -xipo can be linked freely with objects
that are compiled with -xipo.
If you have .o files compiled with the -xipo option from different
compiler versions, mixing these files can result in failure with an
error message about "IR version mismatch". When using the -xipo
option, all the files should be compiled with the same version of
the compiler.
See also: -xjobs.
-xipo_archive={none|readonly|writeback}
Allow crossfile optimization to include archive (.a) libraries.
none
There is no processing of archive files. The compiler does not
apply cross-module inlining or other cross-module optimizations
to object files compiled using -xipo and extracted from an ar‐
chive library at link time. To do that, both -xipo and either
-xipo_archive=readonly or -xipo_archive=writeback must be spec‐
ified 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 compi‐
lation are replaced with their optimized version.
For parallel links that use a common set of archive libraries,
each link should create its own copy of archive libraries to be
optimized before linking.
-xipo_archive requires an argument.
-xipo_build=[yes|no]
Building -xipo without -xipo_build involves two passes through the
compiler -- once when producing the object files, and then again
later at link time when performing the cross file optimization.
Setting -xipo_build reduces compile time by avoiding optimizations
during the initial pass and optimizing only at link time. Optimiza‐
tion is not needed for the object files, as with -xipo it will be
performed at link time. If unoptimized object files built with
-xipo_build are linked without including -xipo to perform optimiza‐
tion, the application will fail to link with an unresolved symbol
error.
Examples:
The following example performs a fast build of .o files, followed
by crossfile optimization at link time:
% cc -O -xipo -xipo_build -o code1.o -c code1.c
% cc -O -xipo -xipo_build -o code2.o -c code2.c
% cc -O -xipo -o a.out code1.o code2.o
The -xipo_build will turn off -O when creating the .o files, to
build these quickly. Full -O optimization will be performed at link
time as part of -xipo crossfile optimization.
The following example links without using -xipo.
% cc -O -o a.out code1.o code2.o
If either code1.o or code2.o were generated with -xipo_build, the
result will be a link-time failure indicating the symbol __unopti‐
mized_object_file is unresolved.
When building .o files separately, the default behavior is
-xipo_build=no. However, when the executable or library is built in
a single pass from source files, -xipo_build will be implicitly
enabled. For example:
% cc -fast -xipo a.c b.c c.c
will implicitly enable -xipo_build=yes for the first passes that
generate a.o, b.o, and c.o. Include the option -xipo_build=no to
disable this behavior.
-xivdep[=p]
Disable or set interpretation of IVDEP directives.
The IVDEP directive tells a compiler to ignore some or all loop-
carried dependences on array references that it finds in a loop for
purposes of optimization. This enables a compiler to perform vari‐
ous loop optimizations such as microvectorization, distribution,
software pipelining, etc., which would not be otherwise possible.
It is used in cases where the user knows either that the depen‐
dences do not matter or that they never occur in practice.
The interpretation of !DIR IVDEP directives depend upon the value
of the -xivdep option.
The following values for p are interpreted as follows:
loop Ignore assumed loop-carried vector dependences.
loop_any Ignore all loop-carried vector dependences.
back Ignore assumed backward loop-carried vector depen‐
dences.
back_any Ignore all backward loop-carried vector dependences.
none Do not ignore any dependences (disables IVDEP direc‐
tives).
These interpretations are provided for compatibility with other
vendor's interpretations of the IVDEP directive.
For details, see the Oracle
Developer Studio 12.6: Fortran User' Guide.
-xjobs={n|auto}
Compile with multiple processes. If this flag is not specified, the
default behavior is -xjobs=auto.
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 overhead among spawned jobs. Also, using a very high num‐
ber can exhaust the limits of system resources such as swap space.
When -xjobs=auto is specified, the compiler will automatically
choose the appropriate number of parallel jobs.
You must always specify -xjobs with a value. Otherwise an error
diagnostic is issued and compilation aborts.
If -xjobs is not specified, the default behavior is -xjobs=auto.
This can be overridden by adding -xjobs=n to the command line. Mul‐
tiple instances of -xjobs on the command line override each other
until the rightmost instance is reached.
Examples:
The following example links with up to 3 parallel processes for
-xipo:
% cc -xipo -xO4 -xjobs=3 t1.o t2.o t3.o
The following example links serially with a single process for
-xipo:
% cc -xipo -xO4 -xjobs=1 t1.o t2.o t3.o
The following example links in parallel, with the compiler choosing
the number of jobs for -xipo:
% cc -xipo -xO4 t1.o t2.o t3.o
Note that this is exactly the same behavior as when explicitly
specifying -xjobs=auto:
% cc -xipo -xO4 -xjobs=auto t1.o t2.o t3.o
-xkeep_unref[={[no%]funcs, [no%]vars}]
Keep definitions of unreferenced functions and variables. The no%
prefix allows the compiler to potentially remove the definitions.
The default is no%funcs,no%vars. Specifying -xkeep_unref is equiva‐
lent to specifying -xkeep_unref=funcs,vars, meaning that
-keep_unref keeps everything.
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named functions.
Specifying %all prohibits stack-related optimizations for all the
code. Specifying %none allows stack-related optimizations for all
the code.
If not specified on the command line, the compiler assumes -xkeep‐
frame=%none
If specified but without a value, the compiler assumes -xkeep‐
frame=%all
This option is accumulative and can appear on the command line mul‐
tiple times. For example, -xkeepframe=%all -xkeepframe=no%func1
indicates that the stack frame should be kept for all functions
except func1. Also, -xkeepframe overrides -xregs=frameptr. For
example, -xkeepframe=%all -xregs=frameptr indicates that the stack
should be kept for all functions, but the optimizations for
-xregs=frameptr would not be done.
-xknown_lib=lib
Recognize calls to a known library.
With this flag specified, the compiler treats references to certain
known libraries as intrinsics, ignoring any user-supplied versions.
This enables the compiler to perform optimizations over calls to
library routines based on special knowledge of that library.
lib may be any one of the following key words, or a comma-delimited
list of a selection of them: blas, blas1, blas2, blas3, intrinsics.
-xknown_lib=[blas | blas1 | blas2 | blas3
]
The compiler recognizes calls to the following BLAS library
routines and is free to optimize appropriately for the Sun Per‐
formance 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:
ctrsm dgemm dsymm dsyr2k dsyrk
dtrmm dtrsm sgemm ssymm ssyr2k
ssyrk strmm strsm zgemm zsymm
zsyr2k zsyrk ztrmm ztrsm
You can select any combination of these. For example
-xknown_lib=blas2,blas3
selects just the BLAS2 and BLAS3 routines.
You can select all the BLAS routines by specifying
-xknown_lib=blas
which is equivalent to
-xknown_lib=blas1,blas2,blas3
The compiler will ignore user-supplied versions of these
library routines and use the BLAS routines in the Sun Perfor‐
mance Library or inline the routines.
The -library=sunperf option is needed to link with the Sun Per‐
formance Library.
-xknown_lib=intrinsics
Specifying intrinsics has the effect of ignoring any explicit
EXTERNAL declarations for Fortran 95 intrinsics, thereby ignor‐
ing any user-supplied intrinsic routines.
For a list of functions recognized by the compiler as intrin‐
sics, see Chapters 2 and 3 of the Fortran Library Reference
manual.
-xl
(Obsolete) This (f77) option is no longer supported. For the equiv‐
alent options in the current Fortran compiler, use:
-f77=%all,no%backslash -vax=$all,no%debug.
-xld
(Obsolete) This (f77) option is no longer supported. For the equiv‐
alent options in the current Fortran compiler, use:
-f77=%all,no%backslash -vax=$all,no%debug.
-xlang=f77
(Obsolete) This option is obsolete and does not do anything since
the Fortran 77 object files are no longer supported. It might be
removed in a future release.
-xlibmil
Synonym for -libmil.
-xlibmopt [={%none,archive,shared}]
Controls whether the compiler uses a library of optimized math rou‐
tines or the standard system math routines. The possible argument
values are:
%none
Do not link with the optimized math library. (This is the
default when no -xlibmopt option is specified.)
archive
Link with the optimized math library in static archive form.
(This is the default when -xlibmopt is specified with no argu‐
ment.)
shared
(Oracle Solaris) Link with the optimized math library in shared
object form.
The rightmost instance of this option on the command line overrides
all previous instances. The order of this option relative to other
libraries specified on the command line is not significant.
The optimized math library includes selected math routines normally
found in libm. The optimized routines typically run faster than
their libm counterparts. The results may be slightly different from
those produced by the libm routines, although in most cases they
differ only in the least significant bit. When the static archive
form of the optimized library is used, the compiler selects rou‐
tines that are optimized for the instruction set indicated by the
-xarch value specified when linking. When the shared object form is
used, the most appropriate routines are selected at runtime based
on the instruction set supported by the system being used.
NOTE: The shared object form is available only on Oracle Solaris.
The routines in the optimized math library depend on the default
round-to-nearest floating point rounding mode. If you use the opti‐
mized math library, you must ensure that round-to-nearest mode is
in effect when any of these routines is called.
Interactions:
-xlibmopt=archive is implied by the -fast option. To disable link‐
ing with the optimized math library when -fast is used, add -xlib‐
mopt=%none following -fast on the command line:
example% cc -fast -xlibmopt=%none ...
See also:
-fast
-xlinkopt[=level]
(Oracle Solaris) Perform link-time optimizations on relocatable
object files.
The post-optimizer performs a number of advanced performance opti‐
mizations 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 opti‐
mizations, at link time.
2 Perform additional data flow analysis, including dead-
code elimination and address computation simplifica‐
tion, 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 pro‐
gram, 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 opti‐
mize 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 fol‐
lows:
% f95 -o progt -xO5 -xprofile=collect:profdir
% progt
% f95 -o prog -xO5 -xprofile=use:prog
For details on using profile feedback, see -xprofile.
Note that compiling with this option will increase link time
slightly. Object file sizes will also increase, but the size of the
executable remains the same. Compiling with -xlinkopt and -g
increases the size of the executable by including debugging infor‐
mation.
Interactions:
-xlinkopt cannot be used together with -xinstrument.
-xloopinfo
Synonym for -loopinfo.
-xM
Generate make dependencies.
This option produces make dependencies for the compiled source file
on standard output. The option covers all make dependencies for the
source file, both header files and Fortran modules.
For module dependencies, this option uses an object-based module
dependency scheme to eliminate the need for explicit build rules to
create the module files.
This option cannot be used with -c, -S, -Xlist, or any other compi‐
lation options that produce different compilation outputs.
The generated dependency output does not contain any build rules,
only dependencies for the files. The user will need to specify the
build rules for all the files needed for the build. However, for
the module files, no explicit build rules are needed, as the module
files are created at the same time as the associated object files.
Therefore, the module files only need to have a generic build rule:
%.mod:
@ echo $@ is already up to date.
The module file build rule is only needed to prevent the 'make'
process from stripping all the dependencies related to module files
if there are no build rules for them. Other than that, the build
rule does not do anything, as shown in the example above.
When used with the -keepmod option, the dependencies generated by
the -xM option will prevent compilation cascade due to the unneces‐
sarily updated modules files, as well as prevent the problem with
recompilation on the same source files due to the use of the -keep‐
mod option to prevent unnecessary updates on the module files.
This option works in conjunction with the -M, -I, and -moddir
options to determine the appropriate directories for the module
files needed in the build. Pre-compiled module files, for example
those shipped by third parties, should be located at a directory
pointed to by the -M option so the correct dependencies can be gen‐
erated.
-xmaxopt[=n]
Enable optimization pragma and set maximum optimization level.
Limits the optimization level specified by a !$PRAGMA SUN OPT=m
directive to n. When a directive specifying a level m greater than
n on the -xmaxopt flag appears, the compiler will use n.
The value n corresponds to the values 1 through 5 of the -O opti‐
mization 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 indeter‐
minable situations. It also specifies the error behavior to be fol‐
lowed 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:
o -xmemalign=8i for 32-bit SPARC platforms (-m32)
o -xmemalign=8s on 64-bit SPARC platforms for C and C++
(-m64)
o -xmemalign=8f on 64-bit SPARC platforms for Fortran
(-m64)
The second default, which applies when -xmemalign appears but with‐
out a value, is -xmemalign=1i for all platforms.
Note that -xmemalign itself does not force a particular data align‐
ment. See -dalign or -aligncommon.
You must also specify -xmemalign whenever you link to an object
file that was compiled with a value of b either i or f.
-xmodel=[a]
(x86) Specify the data address model for shared objects on Oracle
Solaris x64 platforms.
The -xmodel option enables the compiler to create 64-bit shared
objects for the Oracle Solaris x64 platforms and should only be
specified for the compilation of such objects.
This option is invalid when specified with -m32.
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
(Obsolete). Use -xlibmopt=%none instead. See -xlibmopt.
-xO[n]
Synonym for -O[n].
-xopenmp[={parallel|noopt|none}]
Enable explicit parallelization with OpenMP directives.
The flag accepts the following sub-option keywords:
parallel
Enables recognition of OpenMP directives. The optimization
level under -xopenmp=parallel is -xO3. The compiler raises the
optimization level to -xO3 if necessary and issues a warning.
This flag also defines the preprocessor macro _OPENMP. The
_OPENMP macro is defined to have the decimal value yyyymm where
yyyy and mm are the year and month designations of the version
of the OpenMP API that the implementation supports. Refer to
the Oracle Developer Studio 12.6: OpenMP
API User's Guide for the value of the
_OPENMP macro for a particular release.
noopt
Enables recognition of OpenMP directives. The compiler does not
raise the optimization level if it is lower than -xO3. If you
explicitly set the optimization lower than -xO3, as in f95 -xO2
-xopenmp=noopt, the compiler issues an error. If you do not
specify an optimization level with -xopenmp=noopt, the OpenMP
pragmas are recognized, the program is parallelized accord‐
ingly, but no optimization is done. This sub-option also
defines the preprocessor macro _OPENMP.
none
Does not enable the recognition of OpenMP directives, makes no
change to the optimization level of your program, and does not
define any preprocessor macros. This is the default when
-xopenmp is not specified.
If you specify -xopenmp, but do not specify a sub-option keyword,
the compiler assumes -xopenmp=parallel. If you do not specify
-xopenmp at all, the compiler assumes -xopenmp=none.
Sub-options parallel and noopt will turn on -stackvar automati‐
cally.
If you are debugging an OpenMP program with dbx, compile with -g
-xopenmp=noopt so you can breakpoint within parallel regions and
display the contents of variables.
The default for -xopenmp might change in a future release. You can
avoid warning messages by explicitly specifying an appropriate
optimization level.
Use the OMP_NUM_THREADS environment variable to specify the number
of threads to use when running an OpenMP program. If
OMP_NUM_THREADS is not set, the default number of threads used is a
multiple of the number of cores per socket (that is, cores per pro‐
cessor chip), which is less than or equal to the total number of
cores or 32, whichever is less. You can specify a different number
of threads by setting the OMP_NUM_THREADS environment variable, or
by calling the omp_set_num_threads() OpenMP runtime routine, or by
using the num_threads clause on the parallel region directive. For
best performance, the number of threads used to execute a parallel
region should not exceed the number of hardware threads (or virtual
processors) available on the machine. On Oracle Solaris systems,
this number can be determined by using the psrinfo(1M) command. On
Linux systems, this number can be determined by inspecting the file
/proc/cpuinfo. See the Oracle Developer Studio 12.6: OpenMP API
User's
Guide for more information.
Nested parallelism is disabled by default. To enable nested paral‐
lelism, you must set the OMP_NESTED environment variable to TRUE.
See the Oracle Developer Studio 12.6: OpenMP API
User's Guide for details.
If you compile and link in seperate steps, specify -xopenmp in both
the compilation step and the link step. When used with the link
step, the -xopenmp option will link with the OpenMP runtime support
library, libmtsk.so.
For up-to-date functionality and performance, make sure that the
latest patch of the OpenMP runtime library, libmtsk.so, is
installed on the system.
For more information about the OpenMP Fortran 95, C, and C++ appli‐
cation program interface (API) for building multithreaded applica‐
tions, see the Oracle Developer Studio 12.6: OpenMP API
User's Guide.
-xpad
Synonym for -pad.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC: 8K, 64K, 512K, 4M, 32M, 256M, 2G, 16G, or default.
On x86: 4K, 2M, 4M, 1G, or default.
You must specify a valid page size for the Oracle Solaris OS on the
target platform. If you do not specify a valid page size, the
request is silently ignored at run-time.
Use the pagesize(1) Oracle Solaris command to determine the number
of bytes in a page. The operating system offers no guarantee that
the page size request will be honored. However, appropriate segment
alignment can be used to increase the likelihood of obtaining the
requested page size. See the -xsegment_align option on how to set
the segment alignment. You can use pmap(1) or meminfo(2) to deter‐
mine 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 Oracle Solaris command ppgsz(1) with the
equivalent options before running the program. See the Oracle
Solaris OS man pages for details.
The libhugetlbfs library is required for -xpagesize to work on
Linux. See the Linux libhugetlbfs(7) man page for more information.
-xpagesize_heap=n
Set the page size in memory for the heap.
n is the same as described for -xpagesize.
See -xpagesize for further details.
-xpagesize_stack=n
Set the page size in memory for the stack.
n is the same as described for -xpagesize.
See -xpagesize for further details.
-xpatchpadding[={fix|patch|size}]
Reserve an area of memory before the start of each function. If fix
is specified, the compiler will reserve the amount of space
required by fix and continue. This is the default. If either patch
or no value is specified, the compiler will reserve a platform-spe‐
cific default value. A value of -xpatchpadding=0 will reserve 0
bytes of space. The maximum value for size on x86 is 127 bytes and
on SPARC is 2048 bytes.
-xpec[={yes|no}]
Generate a PEC (Portable Executable Code) binary.
This option puts the program intermediate representations in the
object file and the binary. This binary may be used later for tun‐
ing and troubleshooting.
A binary built with -xpec is usually 5 to 10 times larger than if
it is built without.
The default is -xpec=no. Without an argument, -xpec is equivalent
to -xpec=yes.
-xpentium
(Obsolete) Use -xchip=generic instead.
-xpg
Synonym for -pg.
-xpp={fpp|cpp}
Selects the source file preprocessor to be used with .F, .F95, and
.F03 files.
The default is fpp, which is appropriate for Fortran. Previous ver‐
sions of the compiler used cpp, the standard C language preproces‐
sor. To select cpp, specify -xpp=cpp.
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those architectures that
support prefetch. Requires compiling with an optimization level
-xO3 or higher.
a must be one of the following values.
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 execu‐
tion 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 perfor‐
mance across a wide range of machines and applications. This
tuning might not always be optimal. For memory-intensive appli‐
cations, especially applications intended to run on large mul‐
tiprocessors, 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 val‐
ues, use a factor that is less than one.
To use the latx:factor sub-option, start with a factor value
near 1.0 and run performance tests against the application.
Then increase or decrease the factor, as appropriate, and run
the performance tests again. Continue adjusting the factor and
running the performance tests until you achieve optimum perfor‐
mance. 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 sub-options may be
specified.
no
Same as -xprefetch=no%auto,no%explicit. No other sub-options
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 direc‐
tives:
!$PRAGMA SUN_PREFETCH_READ_ONCE (address)
!$PRAGMA SUN_PREFETCH_READ_MANY (address)
!$PRAGMA SUN_PREFETCH_WRITE_ONCE (address)
!$PRAGMA SUN_PREFETCH_WRITE_MANY (address)
The -xchip setting effects the determination of the assumed laten‐
cies and therefore the result of a latx:factor setting.
The latx:factor sub-option 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 circum‐
stances that are supported by measurements.
Because the compiler tunes the prefetch mechanism for optimal per‐
formance across a wide range of machines and applications, you
should only use the latx:factor sub-option when the performance
tests indicate there is a clear benefit. The assumed prefetch
latencies might change from release to release. Therefore, retest‐
ing 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 gen‐
erated.
If you do not specify a setting for -xprefetch_auto_type, the com‐
piler sets it to -xprefetch_auto_type=no%indirect_array_access.
Requires -xprefetch=auto and an optimization level -xO3 or higher.
Options such as -xdepend can affect the aggressiveness of computing
the indirect prefetch candidates and therefore the aggressiveness
of the automatic indirect prefetch insertion due to better memory
alias disambiguation information.
-xprefetch_level=n
Control the degree of insertion of prefetch instructions.
This option is effective only when compiling with -xprefetch=auto,
with optimization level 3 or greater (-xO3), and on a platform that
supports prefetch.
n may be 1, 2, or 3.
The default with -xprefetch=auto is level 2.
Prefetch level 2 finds additional opportunities for prefetch
instructions than level 1. Prefetch level 3 finds additional
prefetch instructions than level 2.
Prefetch levels 2 and 3 may not be effective on older SPARC and x86
platforms.
-xprofile=p
Collects data for a profile or use a profile to optimize.
p must be collect[:profdir], use[:profdir], or tcov[:profdir]
This option causes execution frequency data to be collected and
saved during execution, then the data can be used in subsequent
runs to improve performance. Profile collection is safe for multi‐
threaded applications. That is, profiling a program that does its
own multitasking ( -mt ) produces accurate results. This option is
only valid when you specify -xO2 or greater level of optimization.
If compilation and linking are performed in separate steps, the
same -xprofile option must appear on the compile as well as the
link step.
collect[:profdir]
Collects and saves execution frequency for later use by the
optimizer with -xprofile=use. The compiler generates code to
measure statement execution-frequency.
-xMerge, -ztext, and -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 gener‐
ates statically initialized, position-dependent symbol reloca‐
tions in writable storage.
The profile directory name profdir, if specified, is the path‐
name of the directory where profile data are to be stored when
a program or shared library containing the profiled object code
is executed. If the pathname is not absolute, it is interpreted
relative to the current working directory when the program is
compiled with the option -xprofile=use:profdir.
If no profile directory name is specified with -xprofile=col‐
lect:prof_dir or -xprofile=tcov:prof_dir, profile data are
stored at run time in a directory named program.profile where
program is the basename of the profiled process's main program.
In this case, the environment variables SUN_PROFDATA and
SUN_PROFDATA_DIR can be used to control where the profile data
are stored at run time. If set, the profile data are written to
the directory given by $SUN_PROFDATA_DIR/$SUN_PROFDATA.
If a profile directory name is specified at compilation time,
SUN_PROFDATA_DIR and SUN_PROFDATA have no effect at run time.
These environment variables similarly control the path and
names of the profile data files written by tcov, as described
in the tcov(1) man page.
If these environment variables are not set, the profile data is
written to the directory profdir.profile in the current direc‐
tory, 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 .pro‐
file. If you run the program several times, the execution fre‐
quency data accumulates in the profdir.profile directory; that
is, output from prior executions is not lost.
Example[1]: to collect and use profile data in the directory
myprof.profile located in the same directory where the program
is built:
f95 -xprofile=collect:myprof.profile -xO5 prog.f95 -o prog
./prog
f95 -xprofile=use:myprof.profile -xO5 prog.f95 -o prog
Example[2]: to collect profile data in the directory
/bench/myprof.profile and later use the collected profile data
in a feedback compilation at optimization level -xO5:
f95 -xprofile=collect:/bench/myprof.profile -xO5 prog.f95 \
-o prog
...run prog from multiple locations...
f95 -xprofile=use:/bench/myprof.profile -xO5 prog.f95 -o prog
If you are compiling and linking in separate steps, make sure
that any object files compiled with -xprofile=collect are also
linked with -xprofile=collect.
See also the ENVIRONMENT VARIABLES section of this man page
below for descriptions of environment variables that control
asynchronous profile collections.
use[:profdir]
Uses execution frequency data collected from code compiled with
-xprofile=collect[:profdir] or -xprofile=tcov[:profdir] to
optimize for the work performed when the profiled code was exe‐
cuted. profdir is the pathname of a directory containing pro‐
file data collected by running a program that was compiled with
-xprofile=collect[:profdir] or -xprofile=tcov[:profdir].
To generate data that can be used by both tcov and -xpro‐
file=use[:profdir], the same profile directory must be speci‐
fied at compilation time, using the option -xpro‐
file=tcov[:profdir]. To minimize confusion, specify profdir as
an absolute pathname.
The profdir is optional. If profdir is not specified, the name
of the executible binary is used. a.out is used if -o is not
specified. The compiler looks for profdir.profile/feedback, or
a.out.profile/feedback without profdir specified. For example:
f95 -xprofile=collect -o myexe prog.f95
f95 -xprofile=use:myexe -xO5 -o myexe prog.f95
The program is optimized by using the execution frequency data
previously generated and saved in the feedback files written by
a previous execution of the program compiled with -xpro‐
file=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 compila‐
tion: -xprofile=use:profdir.
See also -xprofile_ircache for speeding up compilation between
collect and use phases.
tcov[:profdir]
Instrument object files for basic block coverage analysis using
tcov(1).
If the optional :profdir argument is specified, the compiler
will create a profile directory at the specified location. The
data stored in the profile directory can be used either by
tcov(1) or by the compiler with -xprofile=use:profdir.
If the optional :profdir argument is omitted, a profile direc‐
tory will be created when the profiled program is executed. The
data stored in the profile directory can only be used by
tcov(1). The location of the profile directory can be con‐
trolled using environment variables SUN_PROFDATA and SUN_PROF‐
DATA_DIR. See ENVIRONMENT VARIABLES below.
If the location specified by :profdir is not an absolute path‐
name, it is interpreted relative to the current working direc‐
tory when the program is compiled.
If :profdir is specified for any object file, the same location
must be specified for all object files in the same program. The
directory whose location is specified by :profdir must be
accessible from all machines where the profiled program is to
be executed. The profile directory should not be deleted until
its contents are no longer needed, because data stored there by
the compiler cannot be restored except by recompilation.
Example 1: if object files for one or more programs are com‐
piled with -xprofile=tcov:/test/profdata, a directory named
/test/profdata.profile will be created by the compiler and used
to store data describing the profiled object files. The same
directory will also be used at execution time to store execu‐
tion data associated with the profiled object files.
Example 2: if a program named "myprog" is compiled with -xpro‐
file=tcov and executed in the directory /home/joe, the direc‐
tory /home/joe/myprog.profile will be created at run time and
used to store runtime profile data.
-xprofile_ircache[=path]
(SPARC) Save and reuse compilation data between collect and use
profile phases.
Use with -xprofile=collect|use to improve compilation time during
the use phase by reusing compilation data saved from the collect
phase.
If specified, path will override the location where the cached
files are saved. By default, these files will be saved in the same
directory as the object file. Specifying a path is useful when the
collect and use phases happen in two different places.
A typical sequence of commands might be:
f95 -xO5 -xprofile=collect -xprofile_ircache t1.f95 t2.f95
a.out // run collects feedback data
f95 -xO5 -xprofile=use -xprofile_ircache t1.f95 t2.f95
With large programs, compilation time in the use phase can improve
significantly by saving the intermediate data in this manner. But
this will be at the expense of disk space, which could increase
considerably.
-xprofile_pathmap=collect_prefix:use_prefix
(SPARC) Set path mapping for profile data files.
Use the -xprofile_pathmap option with the -xprofile=use option.
Use -xprofile_pathmap when the compiler is unable to find profile
data for an object file that is compiled with -xprofile=use, and:
o You are compiling with -xprofile=use into a directory
that is not the directory used when previously compiling
with -xprofile=collect.
o Your object files share a common base name in the pro‐
file 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 direc‐
tory tree in which object files were compiled using -xprofile=col‐
lect.
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 com‐
piler 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 them‐
selves 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 RECUR‐
SIVE. 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 degrada‐
tions.
-xreduction
Synonym for -reduction.
-xregs=r[,r...]
Specify the usage of registers for the generated code.
r is a comma-separated list of one or more of the following sub-
options: appl, float, frameptr.
Prefixing a suboption with no% disables that sub-option.
Example: -xregs=appl,no%float
Note that -xregs sub-options are restricted to specific hardware
platforms.
appl (SPARC)
Allow the compiler to generate code using the application reg‐
isters as scratch registers. The application registers are: g2,
g3, and g4 on 32-bit platforms and g2 and g3 on 64-bit plat‐
forms.
It is strongly recommended that all system software and
libraries be compiled using -xregs=no%appl. System software
(including shared libraries) must preserve these registers'
values for the application. Their use is intended to be con‐
trolled by the compilation system and must be consistent
throughout the application.
In the SPARC ABI, these registers are described as application
registers. Using these registers can increase performance
because fewer load and store instructions are needed. However,
such use can conflict with some old library programs written in
assembly code.
For more information on SPARC instruction sets, see -xarch.
float (SPARC)
Allow the compiler to generate code by using the floating-point
registers as scratch registers for integer values. Use of
floating-point values may use these registers regardless of
this option. To generate binary code free of all references to
floating point registers, use -xregs=no%float and make sure
your source code does not in any way use floating point types.
frameptr (x86)
Allow the compiler to use the frame-pointer register (%ebp on
IA32, %rbp on x86 64-bit platforms) as a general-purpose regis‐
ter.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr unless exceptions are
also disabled with -features=no%except. Note also that
-xregs=frameptr is part of -fast, but is ignored by the C++
compiler unless -features=no%except is also specified.
With -xregs=frameptr the compiler is free to use the frame-
pointer register to improve program performance. However, some
features of the debugger and performance measurement tools may
be limited. Stack tracing, debuggers, and performance analyzers
cannot report on functions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will fail trying to
find cleanup handlers.
Mixed C, Fortran, and C++ code should not be compiled with
-xregs=frameptr if a C++ function, called directly or indi‐
rectly from a C or Fortran function, can throw an exception. If
compiling such mixed source code with -fast, add
-xregs=no%frameptr after the -fast option on the command line.
With more available registers on 64-bit platforms, compiling
with -xregs=frameptr has a better chance of improving 32-bit
code performance than 64-bit code.
Note: -xregs=frameptr is ignored and a warning is issued by the
compiler if you also specify -xpg. Also, -xkeepframe overrides
-xregs=frameptr.
The SPARC default is -xregs=appl,float. The x86 default is
-xregs=no%frameptr. -xregs=frameptr is included in the expansion of
-fast on x86.
It is strongly recommended that you compile code intended for
shared libraries that will link with applications, with
-xregs=no%appl,float. At the very least, the shared library should
explicitly document how it uses the application registers so that
applications linking with those libraries are aware of these regis‐
ter assignments.
For example, an application using the registers in some global
sense (such as using a register to point to some critical data
structure) would need to know exactly how a library with code com‐
piled without -xregs=no%appl is using the application registers in
order to safely link with that library.
-xs[={yes|no}]
(Oracle Solaris) Link debug information from object files into exe‐
cutable.
-xs is the same as -xs=yes. The default for -xdebugformat=dwarf is
the same as -xs=yes.
This option controls the trade-off of executable size versus the
need to retain object files in order to debug. For dwarf, use
-xs=no to keep the executable small but depend on the object files.
This option has almost no effect on dbx performance or the runtime
performance of the program.
When the compile command forces linking (that is, -c is not speci‐
fied) there will be no object file(s) and the debug information
must be placed in the executable. In this case, -xs=no (implicit or
explicit) will be ignored.
The feature is implemented by having the compiler adjust the sec‐
tion flags and/or section names in the object file that it emits,
which then tells the linker what to do for that object file's debug
information. It is therefore a compiler option, not a linker
option. It is possible to have an executable with some object files
compiled -xs=yes and others compiled -xs=no.
Linux compilers accept but ignore -xs. Linux compilers do not
accept -xs={yes|no}.
-xsafe=mem
(SPARC) Allow the compiler to assume that no memory protection vio‐
lations 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, spar‐
cvis2, sparcvis3, for both -m32, and -m64.
-xsecure_code_analysis{=[yes|no]}
Enable or disable compiler secure code analysis to find and display
possible memory safety violations at compile time. Secure code
analysis runs in parallel with the compilation process and may
result in increased compile time.
If -xsecure_code_analysis is not specified or if it is specified
without a yes|no argument, the default is -xsecure_code_analy‐
sis=yes.
Use -xsecure_code_analysis=no to disable secure code analysis.
-xsegment_align=n
(Oracle Solaris) This option causes the driver to include a special
mapfile on the link line. The mapfile aligns the text, data, and
bss segments to the value specified by n. When using very large
pages, it is important that the heap and stack segments are aligned
on an appropriate boundary. If these segments are not aligned,
small pages will be used up to the next boundary, which could cause
a performance degradation. The mapfile ensures that the segments
are aligned on an appropriate boundary.
The n value must be one of the following:
SPARC: The following values are valid: 8K, 64K, 512K, 2M, 4M, 32M,
256M, 1G, and none.
x86: The following values are valid: 4K, 8K, 64K, 512K, 2M, 4M,
32M, 256M, 1G, and none.
The default for both SPARC and x86 is none.
Recommended usage is as follows:
SPARC 32-bit compilation: -xsegment_align=64K
SPARC 64-bit compilation: -xsegment_align=4M
x86 32-bit compilation: -xsegment_align=8K
x86 64-bit compilation: -xsegment_align=4M
The driver will include the appropriate mapfile. For example, if
the user specifies -xsegment_align=4M, the driver adds -M install-
directory/lib/compilers/mapfiles/map.4M.align to the link line,
where install-directory is the installation directory. The afore‐
mentioned segments will then be aligned on a 4M boundary.
-xspace
Do not increase code size.
Do no optimizations that increase the code size. Example: Do not
unroll loops.
-xtarget=t
Specifies the target system for the instruction set and optimiza‐
tion.
t must be one of: native, generic, or system-name.
Each specific value for -xtarget expands into a specific set of
values for the -xarch, -xchip, and -xcache options. Use the
-xdryrun option to determine the expansion of -xtarget=native on a
running system.
For example, -xtarget=T3 is equivalent to -xchip=T3
-xcache=8/16/4:6144/64/24 -xarch=sparcvis3.
cc -dryrun -xtarget=T3 |& grep ###
### command line files and options (expanded):
### -dryrun -xchip=T3 -xcache=8/16/4:6144/64/24 -xarch=sparcvis3
The data type model, either 32-bit or 64-bit, is indicated by the
-m32|-m64 option. To specify the 64-bit data type model, use the
-m64 option as follows:
-xtarget=<value> ... -m64
To specify the 32-bit data type model, use the -m32 option as fol‐
lows:
-xtarget=<value> ... -m32
See also the -m32|-m64 option for a discussion of the default data
type model.
The expansion of -xtarget for a specific host system might not
expand to the same -xarch, -xchip, or -xcache settings as -xtar‐
get=native when compiling on that system.
The following values for t are valid on all systems:
native
Equivalent to
âxarch=native âxchip=native âxcache=native
to give best performance on the host system.
generic
Equivalent to
âxarch=generic âxchip=generic âxcache=generic
to give best performance on most systems. This is the default.
system-name
Get the best performance for the specified system.
Select a system name from the following lists that represents
the actual system you are targeting.
Valid SPARC system names are: sparc64vi (Obsolete), sparc64vii
(Obsolete), sparc64viiplus, sparc64x, sparc64xplus, sparc64xii,
ultraT1 (Obsolete), ultraT2 (Obsolete), ultraT2plus, T3 (Obso‐
lete), T4, T5, T7, M5, M6, and M7.
Valid x86 system names are: barcelona (Obsolete), haswell, ivy‐
bridge, nehalem, pentium (Obsolete), pentium_pro (Obsolete),
pentium3 (Obsolete), pentium4, penryn, sandybridge, westmere,
woodcrest, and broadwell and skylake.
-xtemp=path
Equivalent to -temp=path.
-xthroughput[={yes|no}]
The -xthroughput option tells the compiler that the application
will be run in situations where many processes are simultaneously
running on the system.
If -xthroughput=yes, the compiler will favor optimizations that
slightly reduce performance for a single process while improving
the amount of work achieved by all the processes on the system. As
an example, the compiler might choose to be less aggressive in
prefetching data. Such a choice would reduce the memory bandwidth
consumed by the process, and as such the process may run slower,
but it would also leave more memory bandwidth to be shared among
other processes.
The default is -xthroughput=no.
-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 COM‐
PLEX is mapped as two REAL data elements. Also, DOUBLE COMPLEX will
be treated the way DOUBLE is mapped. For more information, see the
Oracle Developer Studio 12.6: Fortran
User' Guide.
-xunboundsym={yes|no}
Specify whether the program contains references to dynamically
bound symbols.
-xunboundsym=yes means the program contains references dynamically
bound symbols.
-xunboundsym=no means the program does not contain references to
dynamically bound symbols.
The default is -xunboundsym=no.
-xunroll=n
Synonym for -unroll=n.
-xvector[=a]
Enables automatic generation of calls to the vector library and/or
the generation of the SIMD (Single Instruction Multiple Data)
instructions on processors that support SIMD. You must use default
rounding mode by specifying -fround=nearest when you use this
option.
The -xvector option requires optimization level -xO3 or greater.
The option is silently ignored if the optimization level is lower
than -xO3.
a is the equivalent of the following:
[no%]lib
(Oracle Solaris) Enables the compiler to transform math library
calls within loops into single calls to the equivalent vector
math routines when such transformations are possible. This
could result in a performance improvement for loops with large
loop counts. Use no%lib to disable this option.
[no%]simd
(SPARC) For -xarch=sparcace, -xarch=sparcaceplus and
-xarch=sparcace2, directs the compiler to use floating point
and integral SIMD instructions to improve the performance of
certain loops. Contrary to that of the other SPARC -xarch val‐
ues under -xarch=sparcace, -xarch=sparcaceplus and -xarch=spar‐
cace2, -xvector=simd is in effect unless -xvector=none or
-xvector=no%simd has been specified. In addition -xO4 or
greater is required for -xvector=simd, otherwise -xvector=simd
is ignored.
For all other -xarch values, directs the compiler to use the
Visual Instruction Set [VIS1, VIS2, ViS3, etc.] SIMD instruc‐
tions to improve the performance of certain loops. Basically
with explicit -xvector=simd option, the compiler will perform
loop transformation enabling the generation of special vector‐
ized SIMD instructions to reduce the number of loop iterations.
In addition to the optimization level requirement noted below,
the -xvector=simd option is effective only if -xarch=sparcvis3
and above.
[no%]simd
(x86) Directs the compiler to use the native x86 SSE SIMD
instructions to improve performance of certain loops. Streaming
extensions are used on x86 by default at optimization level 3
and above where beneficial. Use no%simd to disable this option.
The compiler will use SIMD only if streaming extensions exist
in the target architecture; that is, if target ISA is at least
SSE2. For example, you can specify -xtarget=woodcrest,
-xarch=generic, -xarch=sse2, -xarch=sse3, or -fast on a modern
platform to use it. If the target ISA has no streaming exten‐
sions, the sub-option will have no effect.
%none
Disable this option entirely.
yes
This option is deprecated, specify -xvector=lib instead.
no
This option is deprecated, specify -xvector=%none instead.
On x86, the default is -xvector=simd. On SPARC, the default is
-xvector=simd under -xarch=sparcace, -xarch=sparcaceplus and
-xarch=sparcace2, and -xvector=%none on other SPARC -xarch values.
If you specify -xvector without a sub-option, the compiler assumes
-xvector=simd,lib on x86 Oracle Solaris, -xvector=lib on SPARC Ora‐
cle Solaris, and -xvector=simd on Linux platforms.
This option overrides previous instances so -xvector=%none undoes a
previously specified -xvector=lib.
The compiler includes the libmvec libraries in the load step. If
you specify -xvector at compile time, you must also specify it at
link time.
-xvpara
Synonym for -vpara.
-ztext
Make no library with relocations.
Do not make the library if relocations remain. The general purpose
of -ztext is to verify that the generated library is pure text;
instructions are all position-independent code. Therefore, it is
generally used with both -G and -pic.
With -ztext, if ld finds an incomplete relocation in the text seg‐
ment, 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 and -xprofile=collect should not be used together. -ztext
prohibits position-dependent symbol relocations in read-only stor‐
age, and -xprofile=collect generates statically initialized, posi‐
tion-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 ear‐
lier run, or libraries of routines that are f95-compatible. These pro‐
grams, 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 com‐
piler 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 subpro‐
grams (see the -M option flag.)
.mod
Files containing precompiled MODULE program units. These are gener‐
ated by the compiler. See the -M option flag.
DIRECTIVES
General Directives
f95 allows general compiler directive lines starting with C$PRAGMA, (in
fixed-format only), or !$PRAGMA, and either uppercase or lowercase is
allowed.
!$PRAGMA C(list_of_subprogram_names)
!$PRAGMA SUN UNROLL n
!$PRAGMA WEAK function_name
!$PRAGMA SUN OPT=n
!$PRAGMA PIPELOOP=n
!$PRAGMA SUN_PREFETCH_READ_ONCE (name)
!$PRAGMA SUN_PREFETCH_READ_MANY (name)
!$PRAGMA SUN_PREFETCH_WRITE_ONCE (name)
!$PRAGMA SUN_PREFETCH_WRITE_MANY (name)
!$PRAGMA IGNORE_TKR list
!$PRAGMA ASSUME (expression [, probability])
Parallelization Directives
f95 recognizes the OpenMP API parallelization directives. OpenMP is the
recommended model for explicit parallelization for all the Oracle
Developer Studio compilers.
In this release, the f95 compiler accepts Version 2.5 of the OpenMP
Fortran 95 API. These have the sentinel !OMP.
For detailed information on the Oracle Developer Studio OpenMP imple‐
mentation, see the Oracle Developer Studio 12.6: OpenMP API
User's Guide.
ENVIRONMENT VARIABLES
The paths shown below assume the root of the Oracle Developer 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 envi‐
ronment variable:
<install-directory>/man/
MODDIR
Specifies the path to the directory where the compiler will write
.mod module files. See also -moddir, which takes precedence over
the setting of the MODDIR environment variable.
LD_LIBRARY_PATH
Generally, you need not set up LD_LIBRARY_PATH. If you do need to
do so, then maybe there is some discrepancy in the installation, or
some executable has been built incorrectly.
Set the LD_LIBRARY_PATH, environment variable to:
<install-directory>/lib/
LD_LIBRARY_PATH_64
Like the LD_LIBRARY_PATH environment variable, LD_LIBRARY_PATH_64
sets the path for searching for 64-bit libraries.
When running in a 64-bit enabled Oracle Solaris OS and linking in
32-bit mode, LD_LIBRARY_PATH_64 is ignored. If only LD_LIBRARY_PATH
is defined, it us used for both 32-bit and 64-bit linking. If both
LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 are defined, the 32-bit
linking will be done using LD_LIBRARY_PATH and the 64-bit linking
using LD_LIBRARY_PATH_64.
See Oracle Solaris 11.3 Linkers and Libraries Guide for more infor‐
mation on these environment variables.
LD_RUN_PATH
If you use LD_RUN_PATH, note that for f95, LD_RUN_PATH is not iden‐
tical with -R. (For ld.so, they are identical.) See -R in the Ora‐
cle Developer Studio 12.6: Fortran
User' Guide for details.
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 is not a valid
directory, the compiler will use /tmp). The -temp option has prece‐
dence 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 work‐
ing directory at the time that the program is executed. If the
optional argument :profdir was specified in -xprofile=col‐
lect[: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=col‐
lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no effect.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchronous profile col‐
lection. In asynchronous profile collection, profile data are col‐
lected 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 envi‐
ronment 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(3LIB) with mmap-based allocation
specified by setting UMEM_OPTIONS to backend=mmap.
Example: to enable asynchronous profile collection from a 64 bit
process at 1 minute intervals,specify the following environment
variables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
SUN_PROFDATA_ASYNC_VERBOSE=verbose
If set nonzero, enables verbose messages from asynchronous collec‐
tor to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no effect unless
asynchronous profile collection is enabled.
SUN_PROFDATA_CLEANUP_AFTER_EXIT=[0|1]
If set to 1, enables profiler to clean up its data structures
between the time that the process calls exit() and the time that
process exit is complete. If set to 0, avoids destructive interfer‐
ence with profile collection by application threads that have not
terminated before the application calls exit(). See exit(3C) for
details. The default setting is SUN_PROFDATA_CLEANUP_AFTER_EXIT=0.
SUN_PROFDATA_REPLACE={objfile,program,all}
SUN_PROFDATA_REPLACE indicates the scope of profile data to be
reset when a changed version of an object file is detected at run‐
time. Use SUN_PROFDATA_REPLACE to ensure that profile data are con‐
sistent with the profiled program within the specified unit of pro‐
gram scope.
The values of SUN_PROFDATA_REPLACE and their meanings are as fol‐
lows:
objfile
Reset profile data of changed object file.
program
Reset profile data of all object files in program containing
changed object file.
all
Reset entire contents of profile directory if any object file
has changed.
The default setting of SUN_PROFDATA_REPLACE is SUN_PROF‐
DATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh)
$ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a changed object file
is executed, all object files in the program will have their pro‐
file data reset. Relevant options include -xOn and -xipo=n.
Refer to the Oracle Developer Studio
12.6: OpenMP API User's Guide for information about the fol‐
lowing environment variables that can be set for an OpenMP program or a
program automatically parallelized by the -xautopar compiler option:
o OMP_SCHEDULE
o OMP_NUM_THREADS
o OMP_DYNAMIC
o OMP_PROC_BIND
o OMP_PLACES
o OMP_NESTED
o OMP_STACKSIZE
o OMP_WAIT_POLICY
o OMP_MAX_ACTIVE_LEVELS
o OMP_THREAD_LIMIT
o OMP_CANCELLATION
o OMP_DISPLAY_ENV
o PARALLEL
o SUNW_MP_WARN
o SUNW_MP_THR_IDLE
o SUNW_MP_PROCBIND
o SUNW_MP_MAX_POOL_THREADS
o SUNW_MP_MAX_NESTED_LEVELS
o STACKSIZE
o SUNW_MP_GUIDED_WEIGHT
o SUNW_MP_WAIT_POLICY
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)
libfsu_db.so.1
Fortran debugging support library
libfsu.so.1
Fortran runtime library
libm.so
System math library
libmmheap.so.1
Memory allocator for Oracle Developer Studio compilers and runtimes
libmtsk_db.so.1
Debugging support library for -xautopar and -xopenmp
libmtsk.so.1
Runtime library for -xautopar and -xopenmp
libmvec.so.1
System vector math library
libstkovf.so.1
Runtime library for stack overflow diagnosis
libsunmath.so.1
System math library extensions
libsunperf.so
Sun Performance library
libtdf.so.1
File access library for -xprofile
libxprof_audit.so.1
Linker audit library for -xprofile
libxprof.so.1
Runtime library for -xprofile
llib-lm
System math lint library
llib-lm.ln
System math lint library
llib-lsunmath
System math extensions lint library
llib-lsunmath.ln
System math extensions lint library
The following reside in the Oracle Developer Studio installation direc‐
tory, 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. On Oracle Solaris, the shared library
libfsu.so is bundled with the operating system.
libfui
Legacy f95 UNIX interface library
libf*ai
Legacy Fortran 95 array intrinsics libraries
libifai
Fortran 95 interval array intrinsics library
libsunmath
Oracle Developer Studio math library. On Oracle Solaris, the shared
library libsunmath.so is bundled with the operating system.
libsunimath
Oracle Developer Studio interval math library
SEE ALSO
Complete Oracle Developer Studio documentation for this release is
available on the Oracle Technical Network website:
http://oracle.com/technetwork/server-storage/developerstudio
Consult the following man pages for additional information: 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:
Oracle Developer Studio 12.6: Fortran
User' Guide
Fortran Programming Guide
Oracle Developer Studio 12.6: OpenMP API
User's Guide
Oracle Developer Studio 12.6: Numerical
Computation Guide
Oracle Developer Studio 12.6: Performance
Analyzer
Fortran Library Reference
Oracle Solaris 11.3 Linkers and Libraries GuideSolaris
Oracle Developer Studio 12.6: Debugging a
Program with dbx
Sun Performance Library User's Guide: The Sun Performance Library con‐
tains subroutines and functions for operations in computational linear
algebra and Fourier transforms.
You can find much more information on the Oracle Developer Studio web
site:
http://oracle.com/technetwork/server-storage/developerstudio
DIAGNOSTICS
The diagnostics produced by f95 itself are intended to be self-explana‐
tory. Occasional messages can be produced by the linker.
Studio 12.6 May 2017 f95(1)