f95, f90 - Fortran 95 compiler
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 ]
Oracle Developer Studio 12.6 Fortran 95 compiler, version 8.8.
The f95 compiler accepts standard-compliant Fortran 95 source code programs. It also accepts some Fortran 2003 features, and the OpenMP[tm] Fortran 95 API version 3.1. It also accepts many FORTRAN 77 (f77) language extensions under the -f77 compatibility option, and VAX VMS Fortran extensions (-vax).
Version 8.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 platforms, 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://oracle.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’s Guide and the Fortran Programming Guide.
See the Oracle Developer Studio 12.6: Fortran User’s Guide for complete details on how to use the f95 compiler. The user guide details all the options, pragma directives, and environment variables accepted by f95, and describes any differences between standard Fortran 95 and this Fortran 95 compiler.
See the Fortran Programming Guide for information on program performance and optimization, parallelization, and porting from other Fortran platforms.
A list of relevant Oracle Developer Studio documentation appears at the end of this man page.
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 definition, and should be used only to specify the instruction set of the target processor.
The ILP32 model specifies that C-language int, long, and pointer data types are 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 running a 64-bit kernel. Compilation, linking, and execution of 64-bit objects can only take place in a Oracle Solaris or Linux OS that supports 64-bit execution.
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 features.
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 compiler 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.
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.
The default compiler options file enables the user to specify a set of default options that are applied to all compiles, unless otherwise overridden. For example, the file could specify that all compiles default at -xO2, or automatically include the file setup.il.
At startup, the compiler searches for a default options file listing default options it should include for all compiles. The environment variable SPRO_DEFAULTS_PATH specifies a colon-separated list of directories to search for the the defaults file.
If the environment variable is not set, a standard set of defaults is used. If the environment variable is set but is empty, no defaults are used.
The defaults file name must be of the form compiler.defaults, where compiler is one of the following: cc, c89, c99, CC, ftn, or lint. For example, the defaults for the Fortran compiler would be ftn.defaults
If a defaults file for the compiler is found in the directories listed in SPRO_DEFAULTS_PATH, the compiler will read the file and process the options prior to processing the options on the command line. The first defaults file found will be used and the search terminated.
System administrators may create system-wide default files in Studio-install-path/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 command line, -xO2 will be used.
Some options appearing in the default options file will be appended after the options specified on the command line. These are the preprocessor option -I, linker options -B, -L, -R, and -l, and all file arguments, such as source files, object files, archives, and shared objects.
The following is an example of how a user-supplied default compiler option startup file might be used.
demo% cat /project/defaults/ftn.defaults -fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara demo% setenv SPRO_DEFAULTS_PATH /project/defaults demo% f95 -c -I/local/hdrs -L/local/libs -lliblocal tst.f
The compiler command is now equivalent to:
f95 -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.f -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way to set the defaults for an entire project, it can become the cause of hard to diagnose problems. Set the environment variable SPRO_DEFAULTS_PATH to an absolute path rather than the current directory to avoid such problems.
The interface stability of the default options file is uncommitted. The order of option processing is subject to change in a future release.
Options valid only on SPARC platforms are marked (SPARC).
Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be used going forward. They are provided only for compatibility with earlier releases. Use the indicated replacement option.
See ld(1) for linker options.
f95 compiles "silently". Except for error and warning messages, it does not issue "progress" messages during compilation.
In general, processing of the compiler options is from left to right, permitting selective overriding of macro options. This rule does not apply to linker or preprocessor options.
In the syntax of the command-line options, items shown in square brackets ( [] ) are optional. Curly brackets enclose a bar-separated list of literal items to be chosen, as in {yes | no | maybe } . The first item in a list usually indicates the default value when the flag appears without a value.
For example, -someoption[={no|yes}] implies -someoption is the same as -someoption=no.
The following options are supported:
Specify alignment of data in common blocks and standard numeric sequence types.
The value specified indicates the maximum alignment (in bytes) for data elements within common blocks and standard numeric sequence types. For example, -aligncommon=4 would align common block data elements with natural alignments of 4 bytes or more on 4-byte boundaries. This option does not affect data with natural alignment smaller than the specified size.
The default, when -aligncommon is not specified, aligns common block and standard numeric sequence data on at most 4-byte boundaries.
Specifying -aligncommon without a value defaults to 1 on all platforms: All data aligns on byte boundaries (no padding between elements).
-aligncommon=16 reverts to -aligncommon=8 when compiling with –m32.
Using -aligncommon=1 on SPARC platforms might result in a bus error due to misalignment, requiring an appropriate choice of the -xmemalign option be used. Depending on the application, -xmemalign=1s, -xmemalign=4ior -xmemalign=8i should give optimal performance while avoiding the segmentation fault.
See also: -xmemalign
Identify nonstandard extensions.
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.
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 warning is issued.
Note that –autopar does not enable the recognition of OpenMP direcives. 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 determined by inspecting the file /proc/cpuinfo. See the Oracle Developer 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.
Prefer dynamic or require static library linking.
This flag indicates that either dynamic library linking is preferred, or static linking required for any libraries listed later in the command. This is a linker option.
Prefer dynamic linking (shared libraries).
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 -Bdynamic requires the same options on a linker command if done in separate 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.
Check array references for out of range subscripts and conformance.
Arrays subscripted beyond their declared sizes can result in unexpected results, including segmentation faults. The -C option checks for possible array subscript violations in the source code and during execution.
With the -C option specified, run-time array subscript violations are treated as an error. The compiler will also flag array subscript range violations in the source code as warnings.
Compiling with -C also adds checks for array conformance at runtime in statements using array syntax.
This option will increase the size of the executable file and degrade execution performance. It should only be used while debugging.
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.
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.
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 symbols. They should appear only on fpp or cpp preprocessor statements, such as conditionals: #ifdef __sparc.
Corresponding older values (prior releases) are: sparc, unix, sun.
These earlier predefined values might be deleted in a future release.
f95 uses the fpp(1) preprocessor by default. Like the C preprocessor cpp(1), fpp expands source code macros and enables conditional compilation of code. Unlike cpp, fpp understand Fortran syntax, and is preferred as a Fortran preprocessor. Use the -xpp=cpp flag to force the compiler to specifically use cpp rather than fpp.
Align COMMON blocks and standard numeric sequence types and generate faster multi-word load/stores.
This flag changes the data layout in COMMON blocks (and EQUIVALENCE classes), and enables the compiler to generate faster multi-word load/stores for that data.
-dalign is a macro equivalent to
-xmemalign=8s -aligncommon=16
Note that –aligncommon=16 is reverted to -aligncommon=8 when compiled 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 subprograms and files in the program unit must be compiled with -dalign.
Because -dalign invokes -aligncommon, the alignment of standard numeric sequence types is also affected.
The -fast flag selects -dalign.
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.
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
Show commands built by the f95 driver but do not compile.
Useful when debugging, this option displays the commands the compiler will run to perform the compilation.
Allow/disallow dynamic libraries for executable
Allow or disallow dynamic libraries for the entire executable. This flag is a linker option.
Allow dynamic libraries.
Do not allow dynamic libraries.
The default is -dy.
Unlike -B{dynamic|static}, this option applies to the whole executable and need appear only once on the command line.
-d{y|n} are linker options. If you compile and link in separate steps with these options, then you need the same option in the final link step.
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.
Suppress warning messages listed by tag name.
This option only affects warning messages. Error messages are not affected. The taglist specifies a list of comma-separated tag names that appear with warning messages. If just %all is specified, all warnings are suppressed (this is equivalent to the -w option.) If just %none is specified, no warnings are suppressed. -erroff specified without a value is equivalent to -erroff=%all.
See also: -errtags
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.
Treat warning messages as errors.
The taglist specifies a list of comma-separated tag names of warning messages that should be treated as errors. If just %all is specified, all warnings are treated as errors. If just %none is specified, no warnings are treated as errors.
See also: -errtags
Create external names with or without underscores.
e must be plain, underscores, or fsecond-underscore.
Do not use trailing underscores.
Use trailing underscores.
Append two underscores to external names that contain an underscore, 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.
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.
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.
Select Fortran 77 compatibility mode.
list is a comma-separated list selected from the following possible keywords:
Select all the f77 compatibility features.
Disable the f77 compatibility features.
Generate f77-style formatted output, including list-directed and namelist output.
Accept input formats allowed by f77.
Enable f77-style TAB-formatting, including unlimited source line length. Also, no blank padding will be added to source lines shorter than 72 characters.
Accept a backslash character as the beginning of an escape sequence in character strings.
Limit recognition of intrinsics to only Fortran 77 intrinsics.
Accept Fortran 77 usage of logical variables, such as:
Allow assignment of integer values to logical variables.
Allow arithmetic expressions in place of logical expressions in conditional statements, with .NE.0 representing .TRUE..
Allow use of relational operators .EQ. and .NE. with logical operands.
Allow non-integer expressions as array subscripts.
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. Specify -ftrap=%none after -f77 to revert to trapping that mimics Fortran 77's behavior.
See the chapter on FORTRAN 77 compatibility in the Oracle Developer Studio 12.6: Fortran User’s Guide for details on -f77 and the compatibility features it provides. See also the -xalias flag for handling nonstandard FORTRAN 77 programming that can cause incorrect results.
A Fortran 77 compiler script has been provided for convenience. The f77 command-line script invokes the f95 compiler with the appropriate set of options for Fortran 77 compatibility. See the f77(1) man page for details.
Select options that optimize execution performance.
-fast provides high performance for certain applications. However, the particular choice of options might not be appropriate for your application. Use -fast as a good starting point for compiling your application for best performance. But additional tuning might still be required. If your program behaves improperly when compiled with -fast, look closely at the individual options that make up -fast and invoke only those appropriate to your program that preserve correct behavior.
Note also that a program compiled with -fast might show good performance and accurate results with some data sets, but not with others. Avoid compiling with -fast those programs that depend on particular properties of floating-point arithmetic.
-fast selects the following options:
-xtarget=native sets the hardware target. If the program is intended to run on a different target than the compilation machine, follow the -fast with the appropriate -xtarget= option. For example:
f95 -fast -xtarget=generic ...
-O5 selects optimization level 5.
-libmil selects inlining of certain math library routines.
-fsimple=2 selects aggressive floating-point optimizations. This option might be unsuited for programs requiring strict IEEE 754 standards compliance.
-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.
-xlibmopt selects linking the optimized math library.
-depend=yes selects dependence analysis to better optimize DO loops. (This option is always selected for optimization levels -O3 and greater.)
-fma=fused enables automatic generation of floating-point fused multiply-add instructions.
-fns selects faster (but nonstandard) handling of floating-point arithmetic exceptions and gradual underflow.
-ftrap=common selects trapping on common floating-point exceptions (this is the default for f95).
-pad=local selects local padding to improve use of cache. (SPARC)
-xvector=lib selects the vectorized math library. (SPARC)
-fround=nearest is selected because -xvector and -xlibmopt require it.
-nofstore cancels forcing expressions to have the precision of the result. (x86)
-xregs=frameptr on x86 allows the compiler to use the frame-pointer register as a general-purpose register. Be sure to read the discussion of -xregs=frameptr especially when compiling mixed C, Fortran, and C++ source codes. Specify -xregs=no%frameptr after -fast and the frame pointer register will not be used as a general purpose register. (x86)
Note that this selection of component option flags is subject to change with each release of the compiler. For details on the options set by -fast, see the Oracle Developer Studio 12.6: Fortran User’s Guide.
To determine the expansion of -fast on a running system, execute the command
f95 -fast -dryrun |& grep ###
It is possible to add or subtract from this list by following the -fast option with other options, as in:
f95 -fast -fsimple=1 -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 floating-point arithmetic, nonstandard alignment of data, and nonstandard ordering of expression evaluation. These selections might not be appropriate for most programs.
Also, because -fast selects -xlibmopt and -xvector=lib, default rounding mode, -fround=nearest, is assumed and required when using -fast.
For separate compile and link steps: if you compile with -fast, then be sure to link with -fast.
Enables/disables the following Fortran language feature.
(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.
Assume fixed-format source input.
Interpret all source files as Fortran 95 fixed-format. Overrides the file suffix.
Synonym for -help.
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 produce different results when compiled with -fma=fused although precision will tend to increase rather than decrease.
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:
Abort on exceptions.
Flush denormalized numbers to zero if it will improve speed.
To be effective, compile the main program with this flag.
See -fns for a information on underflow and handling of denormalized numbers.
The -fnonstd option enables hardware traps for floating-point overflow, division by zero, and invalid operation exceptions. These are converted into SIGFPE signals, and if the program has no SIGFPE handler, it aborts. See ieee_handler(3M), the Oracle Developer Studio 12.6: Numerical Computation Guide, and Fortran Programming Guide for more information.
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 floating-point. The default, -fns=no, utilizes standard floating-point mode.
-fast selects -fns.
On SPARC platforms, nonstandard floating point mode disables "gradual underflow", causing tiny results to be flushed to zero rather than producing subnormal numbers. It also causes subnormal operands to be silently replaced by zero. On those SPARC platforms that do not support gradual underflow and subnormal numbers in hardware, use of this option can significantly improve the performance of some programs.
On x86 platforms, this option is enabled only for Pentium III and Pentium 4 processors (sse or sse2).
On x86, -fns selects SSE flush-to-zero mode and where available, denormals-are-zero mode. This flag causes subnormal results to be flushed to zero. Where available, this flag also causes subnormal operands to be treated as zero.
This flag has no effect on traditional x87 floating-point operations not utilizing the SSE or SSE2 instruction set.
Warning: When nonstandard mode is enabled, floating point arithmetic can produce results that do not conform to the requirements of the IEEE 754 standard. See the Oracle Developer Studio 12.6: Numerical Computation Guide and the Oracle Developer Studio 12.6: Fortran User’s Guide for more information.
This option is effective only if used when compiling the main program.
Detect floating-point overflow in formatted input.
With -fpover=yes specified, the I/O library will detect floating-point overflows in formatted input and cause an arithmetic exception. Combine with -ftrap to get full diagnostic information.
The default is no such overflow detection (-fpover=no). -fpover is equivalent to -fpover=yes.
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
Same as -xopenmp=parallel.
(x86) Initialize non-default floating-point rounding precision mode.
On x86, sets the floating-point precision mode to either single, double, or extended.
When p is single or double, this flag causes the rounding precision mode to be set to single or double precision respectively at program initiation. When p is extended or the -fprecision flag is not used, the rounding precision mode is initialized to extended precision.
This option is effective only on x86 systems and only if used when compiling the main program, but is ignored if compiling for 64-bit platforms (-m64), or SSE2-enabled processors (-xarch=sse2). -fprecision is ignored on SPARC platforms.
Assume free-format source input.
Interpret all source files as Fortran 95 free-format. Overrides the file suffix.
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 rounding direction mode to be set to round-to-zero, round-to-negative-infinity, or round-to-positive-infinity respectively when the program begins execution. When r is nearest or the -fround flag is not used, the rounding direction mode is not altered from its initial value (round-to-nearest by default).
This option is effective only if used when compiling the main program.
Note that compiling with -xvector or -xlibmopt require default rounding. Programs that link with libraries compiled with either -xvector or -xlibmopt or both must ensure that default rounding is in effect.
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 statements 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.
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.
Permit no simplifying assumptions. Preserve strict IEEE 754 conformance.
Allow conservative simplifications. The resulting code does not strictly conform to IEEE 754.
With -fsimple=1, the optimizer can assume the following:
IEEE 754 default rounding/trapping modes do not change after process initialization.
Computations producing no visible result other than potential floating point exceptions might be deleted.
Computations with Infinity or NaNs as operands need not propagate NaNs to their results; e.g., x*0 might be replaced by 0.
Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optimize completely without regard to roundoff or exceptions. In particular, a floating-point computation cannot be replaced by one that produces different results with rounding modes held constant at run time.
In addition to -fsimple=1, permits aggressive floating-point optimizations that can cause many programs to produce different numeric results due to changes in rounding. Also, enables use of SIMD instructions to compute reductions when compiling with -xvector=simd.
In particular, the Fortran standard rule requiring compilers to honor explicit parentheses around subexpressions to control expression evaluation order might be broken with -fsimple=2. This could result in numerical rounding differences with programs that depend on this rule.
For example, with -fsimple=2, the compiler might evaluate C-(A-B) as (C-A)+B, breaking the standard's rule about explicit parentheses, if the resulting code is better optimized. The compiler might also replace repeated computations of x/y with x*z, where z=1/y is computed once and saved in a temporary, to eliminate the costly divide operations.
Programs that depend on particular properties of floating-point arithmetic should not be compiled with -fsimple=2.
-fsimple=2 allows fp-transformations which may introduce fp exceptions.
-fast selects -fsimple=2.
(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.
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:
[Do not] Trap on division by zero.
[Do not] Trap on inexact result.
[Do not] Trap on invalid operation.
[Do not] Trap on overflow.
[Do not] Trap on underflow.
Trap on all the above.
Trap on none of the above.
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.
The –fvisibility=v option is equivalent to the –xldscope option as follows:
-fvisibility=default is equivalent to -xldscope=global
-fvisibility=internal is equivalent to -xldsdope=hidden
-fvisibility=protected is equivalent to -xldscope=symbolic
-fvisibility=hidden is equivalent to -xldscope=hidden
Produce a shared object rather than a dynamically linked executable. This option is passed to ld and cannot be used with the -dn option.
When you use the -G option, the compiler does not pass any default -l options to ld. If you want the shared library to have a dependency on another shared library, you must pass the necessary -l option on the command line.
If you are creating a shared object by specifying -G along with other compiler options that must be specified at both compile time and link time, make sure that those same options are also specified when you link with the resulting shared object. For more information, see the -shared option.
When you create a shared object, all the object files that are compiled for 64-bit SPARC architectures must also be compiled with an explicit -xcode value as documented under the description of -xcode.
See -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 Performance Analyzer, compile with -g. While some performance analysis features do not require -g, you must compile with -g to view annotated source, some function level information, and compiler commentary messages. (See the analyzer(1) man page.)
The commentary messages generated with -g describe the optimizations and transformations the compiler made while compiling your program. You must use er_src(1), er_print(1), or the performance analyzer, analyzer(1) to view the commentary messages.
Note that commentary messages only appear if the compiler actually performed any optimizations. You are more likely to see commentary messages when you request high optimization levels, such as with -xO4, or -fast.
-g is implemented as a macro that expands to various other, more primitive, options. See -xdebuginfo for the details of the expansions.
Values:
Produce standard debugging information.
Do not produce any debugging information. This is the default.
Produce file and line number as well as simple parameter information that is considered crucial during post-mortem debugging.
Same as -g.
Produce additional debugging information, which currently 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.
Equivalent of specifying -xcompress=debug -xcompress_format=cmp-type.
-gz with no sub-option is equivalent to -gz=zlib.
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:
The space between the -h and nm is optional.
-hnm is meaningless without -G.
The names after -h and -o are usually the same.
-hnm is a linker option.
-hnm facilitates versions for dynamic libraries.
List the f95 command-line options.
See also: -xhelp.
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:
the preprocessor directive #include
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:
The directory containing the source file
Directory paths named in -I options
Directories in the default list of the compiler
/usr/include
(There is no -i8 option.)
Use -xtypemap=integer:64 to specify 8-byte INTEGER with this compiler.
Enable/disable inlining of specified user-written routines.
Optimize by inlining the specified user-written routines named in the comma-separated list of functions and subroutines.
The argument list can include the string %auto to enable automatic inlining at optimization levels -O4 or higher. Automatic inlining is normally turned off when explicit inlining is specified on the command line by -inline.
If you prefix the name of a routine on the list with no%, inlining of that routine is inhibited.
For example, to enable automatic inlining while disabling inlining of a specific routine (gflub), use:
-O5 -inline=%auto,no%gflub
An empty list turns off automatic inlining:
-fast -inline=sourcefile.f95
Here, -fast implies -O5, which enables automatic inlining. However, the -inline= with an empty list disables it.
Only routines in the file being compiled are considered. The optimizer decides which of these routines are appropriate for inlining.
A routine is not inlined if any of the following conditions apply, with no warnings:
Optimization is less than -O3.
The routine cannot be found.
Inlining it is not profitable or safe.
The source is not in the file being compiled unless -xipo is also specified.
Set rounding mode for formatted input/output.
Sets the ROUND= specifier globally for all formatted input/output.
With -iorounding=compatible, the value resulting from data conversion is the closer of the two nearest representations, or the value away from zero if the value is halfway between them.
With -iorounding=processor-defined, the rounding mode is the processor's default mode. This is the default when -iorounding is not specified.
Specifying -iorounding without an argument is equivalent to -iorounding=compatible.
Synonym for -pic.
Synonym for -PIC.
If a module file exists and its content is not changed by the latest compilation, it will not be replaced even though the compilation is supposed to create a new module file with the same name. Since the content of the module file is unchanged by the compilation, 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 significantly 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.
Retains the temporary files that are created during compilation.
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.
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 functions 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).
Inline selected libm math library routines for optimization.
Some of the simpler library routines can be inlined by the compiler. This option inlines library calls depending on the floating-point options and platform currently being used.
Link with the Oracle Developer Studio supplied performance libraries.
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.
Specify MODULE directory, archive, or file.
Look in path for Fortran 95 modules referenced in the current compilation. This path is searched in addition to the current directory.
path can specify a directory, .a archive file of precompiled module files, or a .mod precompiled module file. The compiler determines the type of the file by examining its contents.
A .a archive file must be explicitly specified on a -M option flag to be searched for modules. The compiler will not search archive files by default.
Only .mod files with the same names as the MODULE names appearing on USE statements will be searched. For example, the statement USE ME causes the compiler to look only for the module file me.mod.
When searching for modules, the compiler gives higher priority to the directory where the module files are being written. This is controlled by the -moddir flag or the MODDIR environment variable. When neither are specified, the default write-directory is the current directory. When both are specified, the write-directory is the path specified by the -moddir flag.
This means that if only the -M flag appears, the current directory will be searched for modules first before any object listed on the -M flag. To emulate the behavior of previous releases, use:
-moddir=empty-dir -Mdir -M
where empty-dir is the path to an empty directory.
Directories named in -I path will be searched for module files if the files are not found in any of the other locations that are searched.
A space between the -M and the path is allowed. For example, -M /home/siri/PK15/Modules.
On Oracle Solaris, if the path identifies a regular file that is not an archive or a module file, the compiler passes the option to the linker, ld, which will treat it as a linker mapfile. This feature is provided as a convenience similar to the C and C++ compilers.
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
Specify the path to a directory where the compiler will write .mod MODULE files. The path can also be specified by using the MODDIR environment variable. If both are specified, this option flag takes precedence.
The default directory for writing .mod files is the current directory.
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 parallelization API) includes -mt=yes automatically.
Use this option consistently. If you compile and link one translation unit with –mt, you must compile and link all units of the program with –mt.
To determine which system support libraries will be linked by default, compile with the –dryrun option.
See also: -xnolib
Optimize for the host system.
The -native option is a synonym for the -xtarget=native option.
Cancel -autopar on the command line.
Cancel automatic parallelization of loops invoked by -autopar on the command line.
Cancel -depend in command line.
Cancel dependence analysis invoked by a -depend option appearing earlier in the command line.
(x86) Cancel -fstore on command line.
Cancels forcing expressions to have the precision of the destination variable invoked by -fstore.
-nofstore is invoked by -fast. -fstore is the usual default.
Do not link with system libraries.
Do not automatically link with any system or language library; that is, do not pass any default -lx options to ld. The default is to link such libraries into executables automatically, without users specifying them on the command line.
The system and language libraries are required for final execution. It is your responsibility to link them in manually. This option provides you complete control (and responsibility).
The -nolib option makes it easier to link these libraries statically.
Cancel -libmil on command line.
Use with -fast to disable inlining of libm math routines:
demo% f95 -fast -nolibmil ...
Cancel -reduction on command line.
-reduction is used along with parallelization options. This option cancels a -reduction appearing earlier on the command line.
Do not build a runtime library search path into the executable.
If an executable file uses shared libraries, then the compiler normally builds in a path that tells the runtime linker where to find those shared libraries. The path depends on the directory where you installed the compiler. The -norunpath option prevents that path from being built into the executable.
This option is helpful when libraries have been installed in some nonstandard location, and you do not wish to make the loader search down those paths when the executable is run at another site. Compare with -R.
Specify optimization level (n).
If -O[n] is not specified, only a very basic level of optimization limited to local common subexpression elimination and dead code analysis is performed. A program's performance can be significantly improved when compiled with an explicit optimization level.
Each -On level includes the optimizations performed at the levels below it. Generally, the higher the level of optimization, the better the runtime performance. However, higher optimization levels can result in increased compilation time and larger executable files.
There are five optimization levels that you can specify with -On. The actual optimizations performed by the compiler at each level could change with each compiler release.
Use of -O (which implies -O3) or -fast (which implies -O5) is recommended for most programs.
The -g option can be used with optimization.
If the optimizer runs out of memory, it attempts to proceed over again at a lower level of optimization, resuming compilation of subsequent routines at the original level.
For details on optimization, see the Fortran Programming Guide chapters Performance Profiling, and Performance and Optimization.
Optimize at the level most likely to give close to the maximum performance for many realistic applications (equivalent to -O3).
Do only the basic local optimizations (peephole).
Do basic local and global optimization. This level usually gives minimum code size.
Adds global optimizations at the function level, and automatic 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.
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.
Does the highest level of optimization, suitable only for the small fraction of a program that uses the largest fraction of computer time. Uses optimization algorithms that take more compilation time or that do not have as high a certainty of improving execution time. Optimization at this level is more likely to improve performance if it is done with profile feedback. See -xprofile=collect|use.
Interactions:
If you use -g and the optimization level is -O3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.
For more information, see Oracle Developer Studio 12.6: Debugging a Program with dbx.
See also: -fast, -xprofile=p, csh(1) man page
Names the output file filename, instead of the default a.out. filename cannot be the same as sourcefile since cc does not overwrite the source file.
filename must have an appropriate suffix. When used with -c, filename specifies the target .o object file; with -G it specifies the target .so library file. This option and its argument are passed to ld.
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.
Synonym for -xopenmp.
(Obsolete) Compile for profiling with prof.
Prepare object files for profiling with prof(1). This option makes profiles by procedure, showing the number of calls to each procedure and the percent of time used by each procedure.
For separate compile and link steps, and if you compile with -p, then be sure to link with -p.
This option is now obsolete. Use -g and the performance analyzer analyzer(1) instead.
Insert padding for efficient use of cache.
This option inserts padding between arrays or character strings if they are:
static local and not initialized, or
in common blocks.
For either one, the arrays or character strings can not be equivalenced.
If =p is present, it must be one of the following (no spaces):
No padding is done.
Pad local variables.
Pad variables in common blocks.
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:
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.
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.
Padding is dependent on the setting of -xcache. All files must be compiled with the same -xcache settings when -pad=common is used.
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.
EQUIVALENCE declarations involving common block variables will cause warning messages that padding has been inhibited by EQUIVALENCE when compiled with -pad=common. These arrays will not be padded.
It is the programmer's responsibility to make sure that common blocks are compiled consistently when -pad is used. Common blocks appearing in different program units that are compiled inconsistently with -pad=common will cause errors. Compiling with -Xlist will report when common blocks with the same name have different lengths in different program units.
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).
Profiles are generated by using prof or gprof on 64 bit Oracle Solaris platforms or just gprof on 32 bit Oracle Solaris platforms include approximate user CPU times. These times are derived from PC sample data (see pcsample(2)) for routines in the main executable and routines in shared libraries specified as linker arguments when the executable is linked. Other shared libraries (libraries opened after process startup using dlopen(3DL)) are not profiled.
On 32 bit Oracle Solaris systems, profiles generated using prof(1) are limited to routines in the executable. 32 bit shared libraries can be profiled by linking the executable with -xpg and using gprof(1).
The latest Oracle Solaris releases do not include system libraries compiled with -p. As a result, profiles collected on current Oracle Solaris platforms do not include call counts for system library routines.
Note: On x86 systems, -xpg is incompatible with -xregs=frameptr because the gprof runtime library requires a valid frame pointer to determine the return address of a profiled routine. Note also that compiling with -fast on x86 systems will invoke -xregs=frameptr. Compile with the following instead:
-fast -xregs=no%frameptr -xpg
Note: The compiler options -p, -pg, or -xpg should not be used to compile multi-threaded programs, because the runtime support for these options is not thread-safe. If a program that uses multiple threads is compiled with these options invalid results or a segmentation fault could occur at runtime.
For separate compile and link steps, if you compile with -pg, then link with -pg.
Warning: Binaries compiled with -xpg for gprof profiling should not be used with binopt(1), as they are incompatible and can result in internal errors.
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 compile source files when building a shared library. Each reference to a global datum is generated as a dereference of a pointer in the global offset table. Each function call is generated in pc-relative addressing mode through a procedure linkage table.
On SPARC, -PIC is equivalent to -xcode=pic32.
On x86, -PIC is identical to -pic.
(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 assignments to formal parameters.
Pass option list ls to the compilation phase pr.
This option is used primarily by customer service.
Synonym for -p.
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.
Promote single-precision constants to REAL*8 constants.
All single precision literal constants are promoted to REAL*8. Double-precision constants (REAL*8) are not promoted.
This flag applies only to constants. Use -xtypemap to promote both constants and variables.
Use this flag carefully. It could cause interface problems when calling a routine with a REAL*4 literal constant as an actual argument where a REAL*4 value is expected. It could also cause problems with programs reading unformatted data files written by a write statement with a literal REAL*4 constant on its I/O list.
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.
Parallelize reduction operations in loops.
Analyze loops for reduction in automatic parallelization. To enable parallelization of reduction loops, specify both -reduction and -autopar.
Example: demo% f95 -autopar -reduction any.f
A loop that transforms the elements of an array into a single scalar value is called a reduction operation. For example, summing the elements of a vector is a typical reduction operation. Although these operations violate the criteria for parallelization, the compiler can recognize them and parallelize them as special cases when -reduction is specified. See the Fortran Programming Guide chapter Parallelization for information on reduction operations recognized by f95. If you specify -reduction without -autopar, the compiler issues a warning.
There is always potential for roundoff error with reduction.
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).
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.
Produces a shared object rather than a dynamically-linked executable. 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 compiled 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.
Suppress compiler messages.
Normally, f95 does not issue messages, other than error diagnostics, during compilation. This option is provided only for compatibility with older scripts and makefiles. -silent is the default and its use is redundant.
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:
Arguments in a SUBROUTINE or FUNCTION statement (already on stack)
Global items in a COMMON or SAVE, or STATIC statement
Initialized items in a type statement or a DATA statement, such as:
REAL X/8.0/ or DATA X/8.0/
Putting large arrays onto the stack with -stackvar can overflow the stack causing segmentation faults. Increasing the stack size might be required.
The initial thread executing the program has a main stack, while each helper thread of a multithreaded program has its own thread stack.
The default size for the main stack is about 8 Megabytes. The default helper thread stack size is 4 Megabytes on 32-bit platforms and 8 Megabytes on 64-bit platforms.
The limit command (with no parameters) shows the current main stack size.
Use the limit shell command to set the size (in Kilobytes) of the main thread stack. For example, to set the main stack size to 64 Megabytes, use this command:
% limit stacksize 65536
You can set the stack size to be used by each slave thread by giving the STACKSIZE environment variable a value (in Kilobytes):
% setenv STACKSIZE 8192
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 overflow situations.
Enable the STOP statement to return an integer status value.
The optional argument is either yes or no. The default is yes.
With -stop_status=yes a STOP statement can contain an integer constant that will be passed to the environment as the program terminates. This value will be available as $status for the C shell or $? for the Bourne and Korn shells.
The value on the STOP statement can be any positive integer. The value returned to the shell will be modulo 256 (in the range 0 to 255).
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.
Show execution time for each compilation phase.
Issue a stack trace if a severe error occurs in execution.
The -traceback option causes the executable to issue a stack trace to stderr, dump core, and exit if certain signals are generated by the program. If multiple threads generate a signal, a stack trace will only be produced for the first one.
To use traceback, add the -traceback option to the compiler command line when linking. The option is also accepted at compile-time but is ignored unless an executable binary is generated. Using -traceback with -G to create a shared library is an error.
Disables traceback.
Specifies that a stack trace should be issued if any of a set of common signals is generated: sigill, sigfpe, sigbus, sigsegv, and sigabrt.
Specifies a comma-separated list of names of signals which should generate a stack trace, in lower case. The following signals (those that cause the generation of a core file) can be caught: sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe, sigbus, sigsegv, sigsys, sigxcpu, 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 coredumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
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.
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.
Report on undeclared variables.
Equivalent to specifying IMPLICIT NONE in each compilation unit. This has the affect of making the default type of variables undeclared rather than using standard Fortran implicit typing. This option does not override any existing IMPLICIT statements or explicit type statements.
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.
Specify implicit MODULE usage, globally. list is a comma-separated list of module names or module file names. Compiling with -use=module_name in effect adds a USE module_name to each subprogram being compiled. Similarly, compiling with -use=module_file_name effectively adds to each subprogram being compiled a USE module_name for each of the modules contained in the module_file_name file.
Show name and version of each compilation phase.
Verbose mode. Show compilation details.
Like -V but also details the options, macro flag expansions, and environment variables used by the driver.
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.
Interpret blanks in formatted input as zeros on internal files.
Interpret lines starting with the character 'D' to be regular Fortran statements rather than comments, as in VMS Fortran.
Interpret unformatted record size to be in words rather than bytes.
Layout components of a VAX structure in memory as in VMS Fortran, without padding. This option flag replaces the f77 -xl flag. Note: this can cause data misalignments ("bus error") and should be used with -xmemalign to avoid such errors.
Enable all these VAX VMS features. (Default.)
Disable all these VAX VMS features.
Sub-options can be individually selected or turned off (by preceding with no%).
Example:
-vax=debug,rsize,no%blank_zero
The default is -vax=%none. If -vax is specified without any sub-options, it is equivalent to -vax=%all.
Show parallelization warning messages.
Issues warnings about potential parallel programming related problems that may cause incorrect results with with -xopenmp and OpenMP API directives.
Warnings are issued when the compiler detects a problematic use of OpenMP data sharing attributes clauses, such as declaring a variable "shared" whose accesses in an OpenMP parallel region may cause data race, or declaring a variable "private" whose value in a parallel region is used after the parallel region.
No warnings appear if all parallelization directives are processed without issues.
For example, f95 -xopenmp -vpara any.f
Passes the argument arg to component c. Each argument must be separated from the preceding by only a comma. (A comma can be part of an argument by escaping it by an immediately preceding backslash (\) character; the backslash is removed from the resulting argument.) All -W arguments are passed after the regular command-line arguments.
c can be one of the following:
Assembler: (fbe), (gas)
f95 code generator: (cg)(SPARC)
f95 driver
Link editor (ld)
mcs
(Capital letter 'O') Interprocedural optimizer
Postoptimizer
Preprocessor (fpp or cpp)
(The number zero) Compiler (f90comp)
Optimizer: (iropt)
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 override the default name of the dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool with respect to the other specified command line options may change.
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.
Pass arg to the linker, ld.
(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 program. Generates line-numbered source code listing with cross references.
Diagnostic messages from -Xlist are warnings and do not prevent compiling and linking.
Be sure to correct all syntax errors first; -Xlist might produce unpredictable reports when run on a source program with syntax errors.
Output is to a file with a name like the first file name but with a .lst extension.
Example: Errors, listing, and xref to file1.lst
demo% f95 -Xlist file1.f file2.f
Use the -Xlist options to check for interprocedural problems, but only after all other compiler errors and warnings have been resolved.
Summary of -Xlist Sub-options
Default: listings, errors, xref
Call graphs and errors.
Errors only (no xref or listings)
Suppress all -Xlist error messages
Suppress -Xlist error message n.
Errors, listing, and cross references, but no object files compiled.
Terminate if errors detected.
Check include files also
Listings only (no xref)
Page length is n lines
(SPARC) Check OpenMP directives.
Output to nm instead of to file.lst
Suppress unreferenced names from cross-reference table.
Set checking level to n (1,2,3, or 4) - default is 2
Set output line width to n; default is 79
Suppress all -Xlist warning messages
Suppress -Xlist warning message n.
Cross-reference only (no listings)
See the Fortran Programming Guide for details.
(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 creation of a process that is restricted to a 32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is produced.
If the -xaddr32 option is not specified, -xaddr32=no is assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and only on Oracle Solaris platforms supporting SF1_SUNW_ADDR32 software capability.
Since Linux kernel does not support addres space limitation this option is not available on Linux. The -xaddr32 option is ignored on Linux.
When linking, if a single object file was compiled with -xaddr32=yes the whole output file is assumed to be compiled with -xaddr32=yes.
A shared object that is restricted to a 32-bit address space must be loaded by a process that executes within a restricted 32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32 software capabilities definition, described in the Oracle Solaris 11.3 Linkers and Libraries Guide.
Specify degree of aliasing to be assumed by the compiler.
Nonstandard programming techniques can introduce situations that interfere with the compiler's optimization strategies. In particular, the use of overindexing, pointers, and passing global or non-unique variables as subprogram arguments, introduce ambiguous aliasing situations that prevent the compiler from applying certain optimizations, and can introduce ambiguities that could result in unexpected results.
See the Oracle Developer Studio 12.6: Fortran User’s Guide for more information about aliasing.
Use the -xalias flag to inform the compiler about the ways in which the program deviates from the aliasing requirements of the Fortran standard.
The flag may appear with or without a list. The keywords on the list are comma-separated, and each keyword indicates an aliasing situation present in the program. Each keyword may be prefixed by no% to indicate an aliasing type that is not present.
The aliasing keywords are:
Dummy (formal) subprogram parameters can alias each other and global variables.
(Default). Usage of dummy parameters follows the Fortran standard and may not alias each other or global variables.
(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.
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.
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.
(Default). Passing an argument does not result in further aliasing.
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 subprogram. Elements of a sequence-derived type are treated as if they were COMMON blocks. Individual array bounds may be violated, but except as noted above, the referenced array element is assumed to stay within the array.
Array syntax, WHERE, and FORALL statements are not considered for overindexing.
(Default). Array bounds are not violated. Array references do not reference other variables.
Calls to external functions might cause Fortran POINTERS to point at TARGET variables of any type, kind, or rank.
(Default). Fortran pointers follow the rules of the standard.
The default, when -xalias is not specified on the compiler command line, corresponds to:
-xalias=no%dummy,craypointer,no%actual,no%overindex,\
no%ftnpointer
Specifying -xalias without a list gives the best performance for most programs that do not violate Fortran aliasing rules, and corresponds to:
-xalias=no%dummy,no%craypointer,no%actual,no%overindex,\
no%ftnpointer
To be effective, -xalias should be used when compiling with optimization levels -xO3 and higher.
See the chapter on Porting in the Fortran Programming Guide for further details.
Instructs the compiler to create binaries that can later be used by the optimization and observability tools binopt(1), code-analyzer(1), discover(1), collect(1), and uncover(1).
The default 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, -xannotate=yes must be in effect at both compile and link time.
Compile and link with -xannotate=no to produce slightly smaller binaries and libraries when optimization and observability tools will not be used.
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 compatibility with previous releases, as indicated below.
If you compile and link in separate steps, make sure you specify the same value for -xarch in both steps.
Values for all platforms:
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.
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:
Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual Instruction Set (VIS), and without other implementation-specific ISA extensions. This option enables the compiler to generate code for good performance on the V9 ISA.
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.
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.
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 subset of the VIS 3.0 instructions a subset of the SPARC T3 extensions, called the VIS3B subset of VIS 3.0, and the PAUSE and CBCOND instructions from the SPARC T4 extensions.
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.
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.
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.
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.
Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set (VIS) version 1.0, and with UltraSPARC extensions. This option enables the compiler to generate code for good performance on the UltraSPARC architecture.
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.
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
Compile for the sparcfmaf version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction set, plus the UltraSPARC extensions, including the Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III extensions, including the Visual Instruction Set (VIS) version 2.0, and the SPARC64 VI extensions for floating-point multiply-add.
Note that you must use -xarch=sparcfmaf in conjunction with -fma=fused and some optimization level to get the compiler to attempt to find opportunities to use the multiply-add instructions automatically.
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.
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.
Is equivalent to -m64 -xarch=sparcvis and is provided for compatibility with earlier releases.
Is equivalent to -m64 -xarch=sparcvis2 and is provided for compatibility 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 sparcvis2 can be linked and can execute together, but only on a sparcvis2 compatible platform.
For any particular choice, the generated executable could run much more slowly on earlier architectures. Also, although quad-precision floating-point instructions are available in many of these instruction set architectures, the compiler does not use these instructions in the code it generates.
Values specific to x86 platforms:
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 instructions.
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.
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.
May use 386, pentium_pro, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, FSGSBASE, RDRND, and F16C instructions.
May use 386, pentium_pro, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, and PCLMULQDQ instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, and PCLMULQDQ instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1, and SSE4.2 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, and SSE4.1 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, and SSSE3 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, and SSE3 instructions.
Uses the AMD SSE4a Instruction set.
May use 386, MMX, Pentium_pro, SSE, and SSE2 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2 and AMD extension: 3DNow!, 3DNow! extension instructions for AMD processors.
(Obsolete) Use -xarch-generic instead.
May use 386, MMX, Pentium_pro, SEE and AMD extension: 3DNow!, 3DNow! extension instructions for AMD processors.
(Obsolete) Use -xarch-generic instead.
May use 386, MMX, Pentium_pro and AMD extension: 3DNow!, 3DNow! extensions instructions for AMD processors.
Uses the instruction set common to most processor.
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.
Set parameters to control ASSUME pragmas.
Use this flag to control the way the compiler handles ASSUME pragmas in the source code.
See the Oracle Developer Studio 12.6: Fortran User’s Guide for descriptions of the ASSUME pragmas.
The ASSUME pragmas provide a way for the programmer to assert special information that the compiler can use for better optimization. These assertions may be qualified with a probability value. Those with a probability of 0 or 1 are marked as certain; otherwise they are considered non-certain.
Assertions such as whether an upcoming branch will be taken, the range of an integer value or expression, the trip count of an upcoming DO loop, among others, can be made with an associated probability or certainty.
The sub-options recognized are:
The assertions made on ASSUME pragmas affect optimization of the program.
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.
When used with check, the program will terminate when an assertion marked certain is violated.
The d parameter is an optional tolerance value, and must be a real positive constant less than 1. The default is ".1". retrospective compiles code to count the truth or falsity of all assertions. Those outside the tolerance value d are listed on output at program termination.
Ignores all ASSUME pragmas.
If not specified on the compiler command-line, the default is -xassume_control=optimize. This means that the compiler recognizes ASSUME pragmas and they will affect optimization, but no checking is performed.
If specified without parameters, -xassume_control implies -xassume_control=check,fatal. In this case the compiler accepts and checks all certain ASSUME pragmas, but they do not affect optimization. Assertions that are invalid cause the program to terminate.
Synonym for -autopar.
Define cache properties for use by optimizer.
c must be one of the following:
generic
native
s1/l1/a1[/t1]
s1/l1/a1[/t1]:s2/l2/a2[/t2]
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, are defined as follows:
The size of the data cache at level i, in kilobytes
The line size of the data cache at level i, in bytes
The associativity of the data cache at level i
The number of hardware threads sharing the cache at level i The ti parameters are optional. A value of 1 is used if not present.
This option specifies the cache properties that the optimizer can use. It does not guarantee that any particular cache property is used.
Although this option can be used alone, it is part of the expansion of the -xtarget option; its primary use is to override a value supplied by the -xtarget option.
The -xcache values are:
Define the cache properties for good performance on most platforms. This is the default.
Define the cache properties for good performance on this host platform.
Define level 1 cache properties.
Define levels 1 and 2 cache properties.
Define levels 1, 2, and 3 cache properties.
Performs a runtime check for stack overflow of the main thread in a singly-threaded program as well as slave-thread stacks in a multithreaded 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.
Perform all -xcheck checks.
Do not perform any of the -xcheck checks.
Generate code to detect stack overflow errors at runtime, optionally specifying an action to be taken when a stack overflow 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 setting the stack pointer to an invalid but potentially mapped address (see _stack_grow(3C)).
The optional action, if specified, must be one of the following:
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.
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 overflow 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 handler 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 system call depends on how frequently the application creates and destroys new threads.
-xcheck=stkovf is supported only on Oracle Solaris. The C runtime library on Linux does not support stack overflow detection.
Turns off stack-overflow checking.
Perform special initialization of local variables.
With this option the compiler initializes local variables to a value that is likely to cause an arithmetic exception if it is used before it is assigned by the program. Memory allocated by the ALLOCATE statement will also be initialized in this manner.
Module variables, STATIC and SAVE local variables, and variables in COMMON blocks are not initialized.
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, especially when combined with optimization levels greater than -02.
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.
Specify target processor for optimizer.
This option specifies instruction timing properties by specifying the target processor.
Although this option can be used alone, it is part of the expansion of the -xtarget option; its primary use is to override a value supplied by the -xtarget option.
Some effects are:
The ordering of instructions, that is, scheduling
The way the compiler uses branches
The instructions to use in cases where semantically equivalent alternatives are available
Common -xchip values on SPARC are identified below.
Optimize for the SPARC64 VI processor.
Optimize for the SPARC64 VII processor.
Optimize for the SPARC64 VII+ processor.
Optimize for the SPARC64 X processor.
Optimize for the SPARC64 X+ processor.
Optimize for the SPARC64 XII processor.
Optimize for the UltraSPARC T1 chip.
Optimize for the UltraSPARC T2 chip.
Optimize for the UltraSPARC T2+ chip.
Optimize for the SPARC T3 chip.
Optimize for the SPARC T4 chip.
Optimize for the SPARC T5 processor.
Optimize for the SPARC T7 processor.
Optimize for the SPARC M5 processor.
Optimize for the SPARC M6 processor.
Optimize for the SPARC M7 processor.
Optimize for good performance on most supported SPARC platforms. (This is the compiler default.)
Optimize for good performance on this host platform.
The -xchip values on x86 platforms are:
Optimize for the Intel Skylake processor.
Optimize for Intel Broadwell processors.
Optimize for Intel Nahelem processors.
Optimize for Intel Core2 processors.
Obsolete. Use -xchip=generic instead.
Optimize for Intel Pentryn processors.
Optimize for Intel Sandy Bridge processors.
Optimize for the Intel Ivy Bridge processor.
Optimize for the Intel Haswell processor.
Optimize for Intel Westmere processors.
Optimize for AMD Opteron processors.
(Obsolete) Use -xchip=generic instead.
(Obsolete) Use -xchip=generic instead.
(Obsolete) Use -xchip=generic instead.
Optimize for Pentium 4 processors.
Optimize for most x86 platforms.
Optimize for this host processor.
For complete information, see the Oracle Developer Studio 12.6: Fortran User’s Guide.
(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:
This is the default for 32-bit systems. Generates 32-bit absolute addresses. Code + data + bss size is limited to 2**32 bytes.
This is the default for 64-bit systems. Generates 44-bit absolute addresses. Code + data + bss size is limited to 2**44 bytes. Available only on 64-bit architectures.
Generates 64-bit absolute addresses. Available only on 64-bit architectures.
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.
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 section header, sh_name: .got. The sh_size value is the size of the GOT. If the GOT is less than 8,192 bytes, specify -xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine how you should use -xcode:
If you are building an executable you should not use -xcode=pic13 or -xcode=pic32.
If you are building an archive library only for linking into executables you should not use -xcode=pic13 or -xcode=pic32.
If you are building a shared library, start with -xcode=pic13 and once the GOT size exceeds 8,192 bytes, use -xcode=pic32.
If you are building an archive library for linking into shared libraries you should just use -xcode=pic32.
Enable runtime checking of common block inconsistencies.
This option is provided as a debugging aid for programs using task common and parallelization (See the task common pragma.)
Normally, runtime checking for inconsistent task common declarations is disabled. Compiling with -xcommonchk=yes enables runtime checking.
If a common block is declared in one source module as a regular common block, and somewhere else appears in a task common pragma, the program will stop and a message pointing to the first such inconsistency issued.
Because runtime checking degrades program performance, it should only be used during program development and debugging.
Specifying -xcommoncheck alone is equivalent to -xcommoncheck=yes.
Compresses debug sections using the format specified by the -xcompress_format option if supported by the underlying Operating System. A sub-option is required. The option is ignored with a warning when Operating System support is unavailable.
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:
No compression of the debug section is done.
Compresses the debug section using ZLIB compression.
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-sections=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 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).
Control how much debugging and observability information is emitted.
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.
No debugging information is generated. This is the default.
Emit line number and file information.
Emit location list info for parameters. Emit full type information for scalar values (for example, int, char *) and type names but not full definitions of tagtypes.
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.
Emit information for function and variable declarations, member functions, and static data members in class declarations.
Emit full type definitions of tagtypes referenced from param and variable datasets, as well as template definitions.
Emit macro information.
Emit DWARF codetags (also known as Stabs N_PATCH). This is information regarding bitfields, structure copy, and spills used by RTC and discover.
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
Synonym for -depend.
Synonym for -dryrun.
Allow function-level reordering by the Oracle Developer Studio Performance Analyzer.
Allow the reordering of functions (subprograms) in the core image using the compiler, the Analyzer and the linker. If you compile with the -xF option, then run the Analyzer, you can generate a map file that optimizes the ordering of the functions in memory depending on how they are used together. A subsequent link to build the executable file can be directed to use that map by using the linker -Mmapfile option. It places each function from the executable file into a separate section. (The f95 -Mpath option will also pass a regular file to the linker; see the description of the -Mpath option.)
Reordering the subprograms in memory is useful only when the application text page fault time is consuming a large percentage of the application time. Otherwise, reordering might not improve the overall performance of the application. The Performance Analyzer is part of Oracle Developer Studio. See the Oracle Developer Studio 12.6: Performance Analyzer manual for further information on the analyzer.
Support file sharing between little-endian and big-endian platforms.
The flag identifies the byte-order and byte-alignment of unformatted I/O files. options must specify any combination of the following, but at least one specification must be present:
littlemax_align:spec bigmax_align:spec native:spec
max_align declares the maximum byte alignment for the target platform. Permitted values are 1, 2, 4, 8, and 16. The alignment applies to Fortran VAX structures and Fortran 95 derived types that use platform-dependent alignments for compatibility with C language structures.
little specifies a "little-endian" file on platforms where the maximum byte alignment is max_align. For example, little4 specifies a 32-bit x86 file, while little16 describes a 64-bit x86 file.
big specifies a "big-endian" file with a maximum alignment of max_align. For example, big8 describes a 32-bit SPARC file, while big16 describes a 64-bit SPARC file.
native specifies a "native" file with the same byte order and alignment used by the compiling processor platform. The following are assumed to be "native":
PLATFORM "NATIVE" IS 32-bit SPARC big8 64-bit SPARC big16 32-bit x86 little4 64-bit x86 little16
spec must be a comma-separated list of the following: %all, unit, filename.
%all refers to all files and logical units except those opened as "SCRATCH", or named explicitly elsewhere in the -xfilebyteorder flag. %all can only appear once.
unit refers to a specific Fortran unit number opened by the program.
filename refers to a specific Fortran file name opened by the program.
Examples:
-xfilebyteorder=little4:1,2,afile.in,big8:9,bfile.out,12 -xfilebyteorder=little8:%all,big16:20
Notes:
This option does not apply to files opened with STATUS="SCRATCH". I/O operations done on these files are always with the byte-order and byte-alignment of the native processor.
The first default, when -xfilebyteorder does not appear on the command line, is -xfilebyteorder=native:%all.
A file name or unit number can be declared only once in this option.
When -xfilebyteorder does appear on the command line, it must appear with at least one of the little, big, or native specifications.
Files not explicitly declared by this flag are assumed to be native files. For example, compiling with xfilebyteorder=little4:zork.out declares zork.out to be a little-endian 32-bit x86 file with a 4-byte maximum data alignment. All other files in the program are native files.
When the byte-order specified for a file is the same as the native processor but a different alignment is specified, the appropriate padding will be used even though no byte swapping is done. For example, this would be the case when compiling with -m64 for 64-bit x86 platforms and -xfilebyteorder=little4:filename is specified.
The declared types in data records shared between big-endian and little-endian platforms must have the same sizes. For example, a file produced by a SPARC executable compiled with -xtypemap=integer:64,real:64,double:128 cannot be read by an x86 executable compiled with -xtypemap=integer:64,real:64,double:64, since the default double precision data types will have different sizes.
Note that with this release, Oracle Developer Studio sotware now supports REAL*16 data on x86 platforms. Unformatted files containing REAL*16 data can now be used on X86 platforms.
An I/O operation with an entire UNION/MAP data object on a file specified as non-native will result in a runtime I/O error. You can only execute I/O operations using the individual members of the MAP (and not an entire VAX record containing the UNION/MAP) on non-native files.
Control globalization of function-level or file-level static variables.
Globalization is a technique needed by fix and continue functionality 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.
Treat Hollerith constant as character string in actual argument lists.
With -xhasc=yes the compilers treat as character strings Hollerith constants appearing as an actual argument in a subprogram call. This is the default and complies with the Fortran 77 standard.
With -xhasc=no Hollerith constants are treated as typeless values in subprogram call lists.
This flag is provided to aid porting older Fortran programs. Compile routines calling subprograms with Hollerith constants with -xhasc=no if the called subprogram expects that argument as INTEGER or any other type other than CHARACTER.
Show summary of compiler options.
-xhelp=flags is a synonym for -help.
Enable compiler support for dataspace profiling.
When -xhwcprof is enabled, the compiler generates information that helps tools associate profiled load and store instructions with the data-types and structure members (in conjunction with symbolic information produced with -g) to which they refer. It associates profile data with the data space of the target, rather than the instruction space, and provides insight into behavior that is not easily obtained from only instruction profiling.
While you can compile a specified set of object files with -xhwcprof, this option is most useful when applied to all object files in the application. This will provide coverage to identify and correlate all memory references distributed in the application's object files.
If you are compiling and linking in separate steps, use -xhwcprof at link time as well.
An instance of -xhwcprof=enable or -xhwcprof=disable overrides all previous instances of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof without any arguments is the equivalent to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on and that the debug data format be set to dwarf (-xdebugformat=dwarf), which is now the default with this release of the Oracle 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.
Synonym for -inline=rl.
Use this option to manually change the heuristics used by the compiler 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 inlining is on.
In the following sub-options n must be a positive integer; a can be one of the following:
Set the values of all the sub-options to their default values.
Automatic inlining only considers functions smaller than n pseudo instructions (counted in compiler's internal representation) as possible inline candidates.
Under no circumstances will a function larger than this be considered for inlining.
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 function, use -xinline_report=2 to report detailed inlining message and follow the suggestion in the inlining message.
Allow functions to increase due to automatic inlining by up to n pseudo instructions (counted in compiler's internal representation).
The automatic inliner is allowed to increase the size of the program by up to n% where the size is measured in pseudo instructions.
The minimum call site frequency counter as measured by profiling 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).
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.
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.
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 inlining.
When interactions between max_recursive_inst and max_recursive_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 control 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 -xinline_param=default.
The list of values and options accumulate from left to right. So for a specification of -xinline_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
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.
No report is generated.
A summary report of default values of inlining parameters is generated.
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 callsite 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 callsites 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.
Specify this option to compile and instrument your program for analysis by the Thread Analyzer. For more information on the Thread Analyzer, see tha(1) for details.
You can then use the Performance Analyzer to run the instrumented program with collect -r races to create a data-race-detection experiment. You can run the instrumented code standalone but it runs more slowly.
Specify -xinstrument=no%datarace to turn off this feature. This is the default.
-xinstrument must be specified with an argument.
If you compile and link in seperate steps, you must specify -xinstrument=datarace in both the compilation and linking steps.
This option defines the preprocessor token __THA_NOTIFY. You can specify #ifdef __THA_NOTIFY to guard calls to libtha(3) routines.
This option also sets -g.
Interactions:
–xinstrument cannot be used together with –xlinkopt.
Perform interprocedural optimizations.
Invoke interprocedural analysis pass to perform whole-program optimizations. -xipo optimizes across all object files in the link step, and is not limited to just the source files on the compile command.
Analysis and optimization is limited to object files compiled with -xipo.
-xipo=0 disables interprocedural analysis. -xipo=1 enables inlining across source files. -xipo=2 adds whole-program detection and analysis, including memory allocation and memory layout optimizations to improve cache performance.
The default is -xipo=0.
If specified without a value, -xipo=1 is assumed.
When compiling with -xipo=2, there should be no calls from functions or subroutines compiled without -xipo=2 (for example, from libraries) to functions or subroutines compiled with -xipo=2. Otherwise, the assumptions made by the compiler about the usage of these called routines could be incorrect.
See the Fortran 95 User's Guide for additional information about when not to use -xipo.
When compiling and linking in separate steps, you must specify -xipo in both steps to be effective.
Libraries, even if compiled with -xipo do not participate in crossfile interprocedural analysis. Also, .s assembly language source files do not participate in the analysis.
The -xipo flag is ignored if compiling with -S.
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.
Allow crossfile optimization to include archive (.a) libraries.
There is no processing of archive files. The compiler does not apply cross-module inlining or other cross-module optimizations to object files compiled using -xipo and extracted from an archive library at link time. To do that, both -xipo and either -xipo_archive=readonly or -xipo_archive=writeback must be specified at link time.
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.
The compiler optimizes object files passed to the linker with object files compiled with -xipo that reside in the archive library (.a) before producing an executable. Any object filed contained in the library that were optimized during the compilation are replaced with their optimized version.
For parallel links that use a common set of archive libraries, each link should create its own copy of archive libraries to be optimized before linking.
-xipo_archive requires an argument.
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. Optimization 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 optimization, 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 __unoptimized_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.
Disable or set interpretation of IVDEP directives.
The IVDEP directive tells a compiler to ignore some or all loop-carried dependences on array references that it finds in a loop for purposes of optimization. This enables a compiler to perform various loop optimizations such as microvectorization, distribution, software pipelining, etc., which would not be otherwise possible. It is used in cases where the user knows either that the dependences do not matter or that they never occur in practice.
The interpretation of !DIR IVDEP directives depend upon the value of the -xivdep option.
The following values for p are interpreted as follows:
Ignore assumed loop-carried vector dependences.
Ignore all loop-carried vector dependences.
Ignore assumed backward loop-carried vector dependences.
Ignore all backward loop-carried vector dependences.
Do not ignore any dependences (disables IVDEP directives).
These interpretations are provided for compatibility with other vendor's interpretations of the IVDEP directive.
For details, see the Oracle Developer Studio 12.6: Fortran User’s Guide.
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 number 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. Multiple 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
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 equivalent to specifying -xkeep_unref=funcs,vars, meaning that -keep_unref keeps everything.
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 -xkeepframe=%none
If specified but without a value, the compiler assumes -xkeepframe=%all
This option is accumulative and can appear on the command line multiple times. For example, -xkeepframe=%all -xkeepframe=no%func1 indicates that the stack frame should be kept for all functions except func1. Also, -xkeepframe overrides -xregs=frameptr. For example, -xkeepframe=%all -xregs=frameptr indicates that the stack should be kept for all functions, but the optimizations for -xregs=frameptr would not be done.
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.
The compiler recognizes calls to the following BLAS library routines and is free to optimize appropriately for the Sun Performance Library implementation.
BLAS1 routines recognized by -xknown_lib=blas1:
caxpy ccopy cdotc cdotu crotg cscal csrot csscal cswap dasum daxpy dcopy ddot drot drotg drotm drotmg dscal dsdot dswap dnrm2 dzasum dznrm2 icamax idamax isamax izamax sasum saxpy scasum scnrm2 scopy sdot sdsdot snrm2 srot srotg srotm srotmg sscal sswap zaxpy zcopy zdotc zdotu zdrot zdscal zrotg zscal zswap
BLAS2 routines recognized by -xknown_lib=blas2:
cgemv cgerc cgeru ctrmv ctrsv dgemv dger dsymv dsyr dsyr2 dtrmv dtrsv sgemv sger ssymv ssyr ssyr2 strmv strsv zgemv zgerc zgeru ztrmv ztrsv
BLAS3 routines recognized by -xknown_lib=blas3:
ctrsm dgemm dsymm dsyr2k dsyrk dtrmm dtrsm sgemm ssymm ssyr2k ssyrk strmm strsm zgemm zsymm zsyr2k zsyrk ztrmm ztrsm
You can select any combination of these. For example
-xknown_lib=blas2,blas3
selects just the BLAS2 and BLAS3 routines.
You can select all the BLAS routines by specifying
-xknown_lib=blas
which is equivalent to
-xknown_lib=blas1,blas2,blas3
The compiler will ignore user-supplied versions of these library routines and use the BLAS routines in the Sun Performance Library or inline the routines.
The -library=sunperf option is needed to link with the Sun Performance Library.
Specifying intrinsics has the effect of ignoring any explicit EXTERNAL declarations for Fortran 95 intrinsics, thereby ignoring any user-supplied intrinsic routines.
For a list of functions recognized by the compiler as intrinsics, see Chapters 2 and 3 of the Fortran Library Reference manual.
(Obsolete) This (f77) option is no longer supported. For the equivalent options in the current Fortran compiler, use: -f77=%all,no%backslash -vax=$all,no%debug.
(Obsolete) This (f77) option is no longer supported. For the equivalent options in the current Fortran compiler, use: -f77=%all,no%backslash -vax=$all,no%debug.
(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.
Synonym for -libmil.
Controls whether the compiler uses a library of optimized math routines or the standard system math routines. The possible argument values are:
Do not link with the optimized math library. (This is the default when no -xlibmopt option is specified.)
Link with the optimized math library in static archive form. (This is the default when -xlibmopt is specified with no argument.)
(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 routines 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 optimized 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 linking with the optimized math library when -fast is used, add -xlibmopt=%none following -fast on the command line:
example% cc -fast -xlibmopt=%none ...
See also:
-fast
(Oracle Solaris) Perform link-time optimizations on relocatable object files.
The post-optimizer performs a number of advanced performance optimizations on the binary object code at link-time. The value level sets the level of optimizations performed, and must be 0, 1, or 2.
The optimization levels are:
The post-optimizer is disabled. (This is the default.)
Perform optimizations based on control flow analysis, including instruction cache coloring and branch optimizations, at link time.
Perform additional data flow analysis, including dead-code elimination and address computation simplification, at link time.
Specifying -xlinkopt without a level parameter implies -xlinkopt=1.
These optimizations are performed at link time by analyzing the object binary code. The object files are not rewritten but the resulting executable code might differ from the original object codes.
This option is most effective when used to compile the whole program, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear on both compile and link steps:
% f95 -c -xlinkopt a.f95 b.f95 % f95 -o myprog -xlinkopt=2 a.o b.o
Note that the level parameter is only used when the compiler is linking. In the example above, the post-optimization level used is 2 even though the object binaries were compiled with an implied level of 1.
For -xlinkopt to be useful, at least some, but not necessarily all, of the routines in the program must be compiled with this option. The optimizer can still perform some limited optimizations on object binaries not compiled with -xlinkopt.
-xlinkopt will optimize code coming from static libraries that appear on the compiler command line, but it will skip and not optimize code coming from shared (dynamic) libraries that appear on the command line. You can also use -xlinkopt when building shared libraries (compiling with -G).
The link-time post-optimizer is most effective when used with run-time profile feedback. Profiling reveals the most and least used parts of the code and directs the optimizer to focus its effort accordingly. This is particularly important with large applications where optimal placement of code performed at link time can reduce instruction cache misses. Typically, this would be compiled as follows:
% f95 -o progt -xO5 -xprofile=collect:profdir % progt % f95 -o prog -xO5 -xprofile=use:prog
For details on using profile feedback, see -xprofile.
Note that compiling with this option will increase link time slightly. Object file sizes will also increase, but the size of the executable remains the same. Compiling with -xlinkopt and -g increases the size of the executable by including debugging information.
Interactions:
–xlinkopt cannot be used together with –xinstrument.
Synonym for -loopinfo.
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 compilation 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 unnecessarily updated modules files, as well as prevent the problem with recompilation on the same source files due to the use of the -keepmod 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 generated.
Enable optimization pragma and set maximum optimization level.
Limits the optimization level specified by a !$PRAGMA SUN OPT=m directive to n. When a directive specifying a level m greater than n on the -xmaxopt flag appears, the compiler will use n.
The value n corresponds to the values 1 through 5 of the -O optimization level flag. The value of n must be greater or equal to the value of highest optimization level specified by other options. So, for example:
f95 ... -O3 -xmaxopt=4
would be appropriate.
The flag -xmaxopt by itself defaults to -xmaxopt=5.
(SPARC) Specify maximum assumed memory alignment and behavior of misaligned data accesses.
For memory accesses where the alignment is determinable at compile time, the compiler will generate the appropriate load/store instruction sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at compile time, the compiler must assume an alignment to generate the needed load/store sequence.
The -xmemalign flag allows the user to specify the maximum memory alignment of data to be assumed by the compiler in these indeterminable situations. It also specifies the error behavior to be followed at run-time when a misaligned memory access does take place.
Values:
If a value is specified, it must consist of two parts: a numerical alignment value, a, and an alphabetic behavior flag, b.
Allowed values for alignment, a are:
Assume at most 1 byte alignment.
Assume at most 2 byte alignment.
Assume at most 4 byte alignment.
Assume at most 8 byte alignment.
Assume at most 16 byte alignment.
Allowed values for behavior, b are:
Interpret access and continue execution.
Raise signal SIGBUS.
For all SPARC 64-bit platforms, raise signal SIGBUS for alignments less than or equal to 4, otherwise interpret access and continue execution. For all other -xarch values, the f flag is equivalent to i.
Defaults:
The first default, which applies when no -xmemalign flag appears, is:
-xmemalign=8i for 32-bit SPARC platforms (-m32)
-xmemalign=8s on 64-bit SPARC platforms for C and C++ (-m64)
-xmemalign=8f on 64-bit SPARC platforms for Fortran (-m64)
The second default, which applies when -xmemalign appears but without a value, is -xmemalign=1i for all platforms.
Note that -xmemalign itself does not force a particular data alignment. See -dalign or -aligncommon.
You must also specify -xmemalign whenever you link to an object file that was compiled with a value of b either i or f.
(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:
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.
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.
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.
Synonym for -nolib.
Synonym for -nolibmil.
(Obsolete). Use -xlibmopt=%none instead. See -xlibmopt.
Synonym for -O[n].
Enable explicit parallelization with OpenMP directives.
The flag accepts the following sub-option keywords:
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.
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 accordingly, but no optimization is done. This sub-option also defines the preprocessor macro _OPENMP.
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 automatically.
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 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, 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 parallelism, 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++ application program interface (API) for building multithreaded applications, see the Oracle Developer Studio 12.6: OpenMP API User’s Guide.
Synonym for -pad.
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 determine page size of the target platform.
If you specify -xpagesize=default, the flag is ignored. -xpagesize without an argument is the equivalent to -xpagesize=default.
This option is a macro for -xpagesize_heap=n -xpagesize_stack=n. These two options accept the same arguments as -xpagesize. You can set them both with the same value by specifying -xpagesize=n or you can specify them individually with different values.
Compiling with this flag has the same effect as setting the LD_PRELOAD environment variable to mpss.so.1 with the equivalent options, or running the 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.
Set the page size in memory for the heap.
n is the same as described for -xpagesize.
See -xpagesize for further details.
Set the page size in memory for the stack.
n is the same as described for -xpagesize.
See -xpagesize for further details.
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-specific 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.
Generate a PEC (Portable Executable Code) binary.
This option puts the program intermediate representations in the object file and the binary. This binary may be used later for tuning and troubleshooting.
A binary built with -xpec is usually 5 to 10 times larger than if it is built without.
The default is -xpec=no. Without an argument, -xpec is equivalent to -xpec=yes.
(Obsolete) Use -xchip=generic instead.
Synonym for -pg.
Selects the source file preprocessor to be used with .F, .F95, and .F03 files.
The default is fpp, which is appropriate for Fortran. Previous versions of the compiler used cpp, the standard C language preprocessor. To select cpp, specify -xpp=cpp.
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.
Enable automatic generation of prefetch instructions.
Disable automatic generation.
Enable explicit prefetch directives.
Disable explicit prefectch directives.
(SPARC) Adjust the compiler's assumed prefetch-to-load and prefetch-to-store latencies by the specified factor. The factor must be a positive floating-point or integer number.
The prefetch latency is the hardware delay between the execution of a prefetch instruction and the time the data being prefetched is available in the cache.
The compiler assumes a prefetch latency value when determining how far apart to place a prefetch instruction and the load or store instruction that uses the prefetched data. Note -- the assumed latency between a prefetch and a load might not be the same as the assumed latency between a prefetch and a store.
The compiler tunes the prefetch mechanism for optimal performance across a wide range of machines and applications. This tuning might not always be optimal. For memory-intensive applications, especially applications intended to run on large multiprocessors, you might be able to obtain better performance by increasing the prefetch latency values. To increase the values, use a factor that is greater than 1 (one). A value between .5 and 2.0 will most likely provide the maximum performance.
For applications with datasets that reside entirely within the external cache, you might be able to obtain better performance by decreasing the prefetch latency values. To decrease the values, use a factor that is less than one.
To use the latx:factor 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 performance. When you increase or decrease the factor in small steps, you will see no performance difference for a few steps, then a sudden difference, then it will level off again.
Same as -xprefetch=auto,explicit. No other sub-options may be specified.
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 directives:
!$PRAGMA SUN_PREFETCH_READ_ONCE (address) !$PRAGMA SUN_PREFETCH_READ_MANY (address) !$PRAGMA SUN_PREFETCH_WRITE_ONCE (address) !$PRAGMA SUN_PREFETCH_WRITE_MANY (address)
The -xchip setting effects the determination of the assumed latencies and therefore the result of a latx:factor setting.
The latx:factor 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 circumstances that are supported by measurements.
Because the compiler tunes the prefetch mechanism for optimal performance across a wide range of machines and applications, you should only use the latx:factor sub-option when the performance tests indicate there is a clear benefit. The assumed prefetch latencies might change from release to release. Therefore, retesting the effect of the latency factor on performance whenever switching to a different release is highly recommended.
Generate indirect prefetches for a data arrays accessed indirectly.
[no%]indirect_array_access does [not] generate indirect prefetches for the loops indicated by the option -xprefetch_level=[1|2|3] in the same fashion the prefetches for direct memory accesses are generated.
If you do not specify a setting for -xprefetch_auto_type, the compiler sets it to -xprefetch_auto_type=no%indirect_array_access.
Requires -xprefetch=auto and an optimization level -xO3 or higher.
Options such as -xdepend can affect the aggressiveness of computing the indirect prefetch candidates and therefore the aggressiveness of the automatic indirect prefetch insertion due to better memory alias disambiguation information.
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.
Collects data for a profile or use a profile to optimize.
p must be collect[:profdir], use[:profdir], or tcov[:profdir]
This option causes execution frequency data to be collected and saved during execution, then the data can be used in subsequent runs to improve performance. Profile collection is safe for multithreaded applications. That is, profiling a program that does its own multitasking ( -mt ) produces accurate results. This option is only valid when you specify -xO2 or greater level of optimization.
If compilation and linking are performed in separate steps, the same -xprofile option must appear on the compile as well as the link step.
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 generates statically initialized, position-dependent symbol relocations in writable storage.
The profile directory name profdir, if specified, is the pathname of the directory where profile data are to be stored when a program or shared library containing the profiled object code is executed. If the pathname is not absolute, it is interpreted relative to the current working directory when the program is compiled with the option -xprofile=use:profdir.
If no profile directory name is specified with -xprofile=collect:prof_dir or -xprofile=tcov:prof_dir, profile data are stored at run time in a directory named program.profile where program is the basename of the profiled process's main program. In this case, the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR can be used to control where the profile data are stored at run time. If set, the profile data are written to the directory given by $SUN_PROFDATA_DIR/$SUN_PROFDATA.
If a profile directory name is specified at compilation time, SUN_PROFDATA_DIR and SUN_PROFDATA have no effect at run time. These environment variables similarly control the path and names of the profile data files written by tcov, as described in the tcov(1) man page.
If these environment variables are not set, the profile data is written to the directory profdir.profile in the current directory, where profdir is the name of the executable or the name specified in the -xprofile=collect:profdir flag. -xprofile does not append .profile to profdir if profdir already ends in .profile. If you run the program several times, the execution frequency data accumulates in the profdir.profile directory; that is, output from prior executions is not lost.
Example[1]: to collect and use profile data in the directory myprof.profile located in the same directory where the program is built:
f95 -xprofile=collect:myprof.profile -xO5 prog.f95 -o prog ./prog f95 -xprofile=use:myprof.profile -xO5 prog.f95 -o prog
Example[2]: to collect profile data in the directory /bench/myprof.profile and later use the collected profile data in a feedback compilation at optimization level -xO5:
f95 -xprofile=collect:/bench/myprof.profile -xO5 prog.f95 \
-o prog
...run prog from multiple locations...
f95 -xprofile=use:/bench/myprof.profile -xO5 prog.f95 -o prog
If you are compiling and linking in separate steps, make sure that any object files compiled with -xprofile=collect are also linked with -xprofile=collect.
See also the ENVIRONMENT VARIABLES section of this man page below for descriptions of environment variables that control asynchronous profile collections.
Uses execution frequency data collected from code compiled with -xprofile=collect[:profdir] or -xprofile=tcov[:profdir] to optimize for the work performed when the profiled code was executed. profdir is the pathname of a directory containing profile data collected by running a program that was compiled with -xprofile=collect[:profdir] or -xprofile=tcov[:profdir].
To generate data that can be used by both tcov and -xprofile=use[:profdir], the same profile directory must be specified at compilation time, using the option -xprofile=tcov[:profdir]. To minimize confusion, specify profdir as an absolute pathname.
The profdir is optional. If profdir is not specified, the name of the executible binary is used. a.out is used if -o is not specified. The compiler looks for profdir.profile/feedback, or a.out.profile/feedback without profdir specified. For example:
f95 -xprofile=collect -o myexe prog.f95 f95 -xprofile=use:myexe -xO5 -o myexe prog.f95
The program is optimized by using the execution frequency data previously generated and saved in the feedback files written by a previous execution of the program compiled with -xprofile=collect.
Except for the -xprofile option, the source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program which in turn generated the feedback file. The same version of the compiler must be used for both the collect build and the use build as well.
If compiled with -xprofile=collect:profdir, the same profile directory name profdir must be used in the optimizing compilation: -xprofile=use:profdir.
See also -xprofile_ircache for speeding up compilation between collect and use phases.
Instrument object files for basic block coverage analysis using tcov(1).
If the optional :profdir argument is specified, the compiler will create a profile directory at the specified location. The data stored in the profile directory can be used either by tcov(1) or by the compiler with -xprofile=use:profdir.
If the optional :profdir argument is omitted, a profile directory will be created when the profiled program is executed. The data stored in the profile directory can only be used by tcov(1). The location of the profile directory can be controlled using environment variables SUN_PROFDATA and SUN_PROFDATA_DIR. See ENVIRONMENT VARIABLES below.
If the location specified by :profdir is not an absolute pathname, it is interpreted relative to the current working directory when the program is compiled.
If :profdir is specified for any object file, the same location must be specified for all object files in the same program. The directory whose location is specified by :profdir must be accessible from all machines where the profiled program is to be executed. The profile directory should not be deleted until its contents are no longer needed, because data stored there by the compiler cannot be restored except by recompilation.
Example 1: if object files for one or more programs are compiled with -xprofile=tcov:/test/profdata, a directory named /test/profdata.profile will be created by the compiler and used to store data describing the profiled object files. The same directory will also be used at execution time to store execution data associated with the profiled object files.
Example 2: if a program named "myprog" is compiled with -xprofile=tcov and executed in the directory /home/joe, the directory /home/joe/myprog.profile will be created at run time and used to store runtime profile data.
(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.
(SPARC) Set path mapping for profile data files.
Use the -xprofile_pathmap option with the -xprofile=use option.
Use -xprofile_pathmap when the compiler is unable to find profile data for an object file that is compiled with -xprofile=use, and:
You are compiling with -xprofile=use into a directory that is not the directory used when previously compiling with -xprofile=collect.
Your object files share a common base name in the profile but are distinguished from each other by their location in different directories.
The collect-prefix is the prefix of the UNIX path name of a directory tree in which object files were compiled using -xprofile=collect.
The use-prefix is the prefix of the UNIX path name of a directory tree in which object files are to be compiled using -xprofile=use.
If you specify multiple instances of -xprofile_pathmap, the compiler processes them in the order of their occurrence. Each use-prefix specified by an instance of -xprofile_pathmap is compared with the object file path name until either a matching use-prefix is identified or the last specified use-prefix is found not to match the object file path name.
Allow routines defined without RECURSIVE attribute to call themselves recursively.
Normally, only subprograms defined with the RECURSIVE attribute can call themselves recursively.
Compiling with -xrecursive enables subprograms to call themselves recursively even if they are not defined with the attribute RECURSIVE. But, unlike the RECURSIVE attribute, this flag does not cause local variables to be allocated on the stack by default. For each recursive invocation of the subprogram to have separate values for local variables, compile with -stackvar to put local variables on the stack.
Compiling routines with -xrecursive can cause performance degradations.
Synonym for -reduction.
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.
Allow the compiler to generate code using the application registers as scratch registers. The application registers are: g2, g3, and g4 on 32-bit platforms and g2 and g3 on 64-bit platforms.
It is strongly recommended that all system software and libraries be compiled using -xregs=no%appl. System software (including shared libraries) must preserve these registers' values for the application. Their use is intended to be controlled by the compilation system and must be consistent throughout the application.
In the SPARC ABI, these registers are described as application registers. Using these registers can increase performance because fewer load and store instructions are needed. However, such use can conflict with some old library programs written in assembly code.
For more information on SPARC instruction sets, see -xarch.
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.
Allow the compiler to use the frame-pointer register (%ebp on IA32, %rbp on x86 64-bit platforms) as a general-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr unless exceptions are also disabled with -features=no%except. Note also that -xregs=frameptr is part of -fast, but is ignored by the C++ compiler unless -features=no%except is also specified.
With -xregs=frameptr the compiler is free to use the frame-pointer register to improve program performance. However, some features of the debugger and performance measurement tools may be limited. Stack tracing, debuggers, and performance analyzers cannot report on functions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will fail trying to find cleanup handlers.
Mixed C, Fortran, and C++ code should not be compiled with -xregs=frameptr if a C++ function, called directly or indirectly from a C or Fortran function, can throw an exception. If compiling such mixed source code with -fast, add -xregs=no%frameptr after the -fast option on the command line.
With more available registers on 64-bit platforms, compiling with -xregs=frameptr has a better chance of improving 32-bit code performance than 64-bit code.
Note: -xregs=frameptr is ignored and a warning is issued by the compiler if you also specify -xpg. Also, -xkeepframe overrides -xregs=frameptr.
The SPARC default is -xregs=appl,float. The x86 default is -xregs=no%frameptr. -xregs=frameptr is included in the expansion of -fast on x86.
It is strongly recommended that you compile code intended for shared libraries that will link with applications, with -xregs=no%appl,float. At the very least, the shared library should explicitly document how it uses the application registers so that applications linking with those libraries are aware of these register assignments.
For example, an application using the registers in some global sense (such as using a register to point to some critical data structure) would need to know exactly how a library with code compiled without -xregs=no%appl is using the application registers in order to safely link with that library.
(Oracle Solaris) Link debug information from object files into executable.
-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 specified) 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 section 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}.
(SPARC) Allow the compiler to assume that no memory protection violations occur.
This option allows the compiler to use the non-faulting load instruction in the SPARC V9 architecture.
Warnings:
Because non-faulting loads do not cause a trap when a fault such as address misalignment or segmentation violation occurs, you should use this option only for programs in which such faults cannot occur. Because few programs incur memory-based traps, you can safely use this option for most programs. Do not use this option for programs that explicitly depend on memory-based traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with optimization level -xO5 and one of the following -xarch values: sparc, sparcvis, sparcvis2, sparcvis3, for both -m32, and -m64.
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_analysis=yes.
Use –xsecure_code_analysis=no to disable secure code analysis.
(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 aforementioned segments will then be aligned on a 4M boundary.
Do not increase code size.
Do no optimizations that increase the code size. Example: Do not unroll loops.
Specifies the target system for the instruction set and optimization.
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 follows:
-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 -xtarget=native when compiling on that system.
The following values for t are valid on all systems:
Equivalent to
—xarch=native —xchip=native —xcache=native
to give best performance on the host system.
Equivalent to
—xarch=generic —xchip=generic —xcache=generic
to give best performance on most systems. This is the default.
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 (Obsolete), T4, T5, T7, M5, M6, and M7.
Valid x86 system names are: barcelona (Obsolete), haswell, ivybridge, nehalem, pentium (Obsolete), pentium_pro (Obsolete), pentium3 (Obsolete), pentium4, penryn, sandybridge, westmere, woodcrest, and broadwell and skylake.
Equivalent to -temp=path.
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.
Synonym for -time.
Specify default data mappings.
This option provides a flexible way to specify the byte sizes for default data types.
The syntax of the string spec is:
type:bits,type:bits,...
The allowable data types are REAL, DOUBLE, INTEGER. The data sizes accepted are 16, 32, 64, and 128.
This option applies to all variables declared without explicit byte sizes, as in REAL XYZ.
The allowable combinations are:
real:32 real:64 double:64 double:128 integer:16 integer:32 integer:64
A useful mapping is:
-xtypemap=real:64,double:64,integer:64
which maps REAL and DOUBLE to 8 bytes, but does not promote DOUBLE PRECISION to QUAD PRECISION.
Note also that INTEGER and LOGICAL are treated the same, and COMPLEX is mapped as two REAL data elements. Also, DOUBLE COMPLEX will be treated the way DOUBLE is mapped. For more information, see the Oracle Developer Studio 12.6: Fortran User’s Guide.
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.
Synonym for -unroll=n.
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:
(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.
(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 values under –xarch=sparcace, –xarch=sparcaceplus and –xarch=sparcace2, -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 instructions to improve the performance of certain loops. Basically with explicit -xvector=simd option, the compiler will perform loop transformation enabling the generation of special vectorized 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.
(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 extensions, the sub-option will have no effect.
Disable this option entirely.
This option is deprecated, specify -xvector=lib instead.
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 Oracle Solaris, and -xvector=simd on Linux platforms.
This option overrides previous instances so -xvector=%none undoes a previously specified -xvector=lib.
The compiler includes the libmvec libraries in the load step. If you specify -xvector at compile time, you must also specify it at link time.
Synonym for -vpara.
Make no library with relocations.
Do not make the library if relocations remain. The general purpose of -ztext is to verify that the generated library is pure text; instructions are all position-independent code. Therefore, it is generally used with both -G and -pic.
With -ztext, if ld finds an incomplete relocation in the text segment, then it does not build the library. If it finds one in the data segment, then it generally builds the library anyway; the data segment is writeable.
Without -ztext, ld builds the library, relocations or not.
A typical use is to make a library from both source files and object files, where you do not know if the object files were made with -pic.
-ztext and -xprofile=collect should not be used together. -ztext prohibits position-dependent symbol relocations in read-only storage, and -xprofile=collect generates statically initialized, position-dependent symbol relocations in writable storage.
Other arguments are taken to be either linker option arguments, or names of f95-compatible object programs, typically produced by an earlier run, or libraries of routines that are f95-compatible. These programs, together with the results of any compilations specified, are linked in the order given to produce an executable program in the file specified by the -o option, or in a file named a.out if the -o option is not specified.
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.
Fixed format Fortran source files.
Free format Fortran 90, Fortran 95, or Fortran 2003 source files.
Fixed format Fortran source containing preprocessor directives. These files are preprocessed by fpp(1) before they are compiled. (See also the -xpp= option.)
Free format Fortran 95 source containing preprocessor directives. These files are preprocessed fpp(1) before they are compiled. (See also the -xpp= option.)
Assembler source files.
Inline assembler expansion code template files. Used by the compiler to expand calls to selected routines into inline code. See the inline(1) man page and -inline option flag for more information on inline template files.
Object files to be passed to the linker.
Shared object files or libraries to be passed to the linker.
Library files passed to the linker, or searched for MODULE subprograms (see the -M option flag.)
Files containing precompiled MODULE program units. These are generated by the compiler. See the -M option flag.
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])
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 implementation, see the Oracle Developer Studio 12.6: OpenMP API User’s Guide.
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.
To use f95, add the following to the start of the search path:
<install-directory>/bin/
To access the f95 man pages, add the following to the MANPATH environment variable:
<install-directory>/man/
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.
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/
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 information on these environment variables.
If you use LD_RUN_PATH, note that for f95, LD_RUN_PATH is not identical with -R. (For ld.so, they are identical.) See -R in the Oracle Developer Studio 12.6: Fortran User’s Guide for details.
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 precedence over the TMPDIR environment variable.
If set, store profile data collected from a program compiled with -xprofile=collect in a directory named profdir in the current working directory at the time that the program is executed. If the optional argument :profdir was specified in -xprofile=collect[:profdir] at compilation time, SUN_PROFDATA as no effect.
If set, store profile data collected from a program compiled with -xprofile=collect in a directory whose UNIX dirname is dirname. If dirname is not absolute, it is interpreted relative to the current working directory at the time that the program is executed. If the optional argument :profdir was specified in -xprofile=collect[:profdir] at compilation time, SUN_PROFDATA_DIR has no effect.
Set this environment variable to enable asynchronous profile collection. In asynchronous profile collection, profile data are collected from a running process at regular intervals whose duration is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64 is set to /usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-safe, mmap based memory allocator, such as libumem(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]
If set nonzero, enables verbose messages from asynchronous collector to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no effect unless asynchronous profile collection is enabled.
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 interference 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 indicates the scope of profile data to be reset when a changed version of an object file is detected at runtime. Use SUN_PROFDATA_REPLACE to ensure that profile data are consistent with the profiled program within the specified unit of program scope.
The values of SUN_PROFDATA_REPLACE and their meanings are as follows:
Reset profile data of changed object file.
Reset profile data of all object files in program containing changed object file.
Reset entire contents of profile directory if any object file has changed.
The default setting of SUN_PROFDATA_REPLACE is SUN_PROFDATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh) $ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a changed object file is executed, all object files in the program will have their profile data reset. Relevant options include -xOn and -xipo=n.
Refer to the Oracle Developer Studio 12.6: OpenMP API User’s Guide for information about the following environment variables that can be set for an OpenMP program or a program automatically parallelized by the –xautopar compiler option:
OMP_SCHEDULE
OMP_NUM_THREADS
OMP_DYNAMIC
OMP_PROC_BIND
OMP_PLACES
OMP_NESTED
OMP_STACKSIZE
OMP_WAIT_POLICY
OMP_MAX_ACTIVE_LEVELS
OMP_THREAD_LIMIT
OMP_CANCELLATION
OMP_DISPLAY_ENV
PARALLEL
SUNW_MP_WARN
SUNW_MP_THR_IDLE
SUNW_MP_PROCBIND
SUNW_MP_MAX_POOL_THREADS
SUNW_MP_MAX_NESTED_LEVELS
STACKSIZE
SUNW_MP_GUIDED_WEIGHT
SUNW_MP_WAIT_POLICY
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:
Standard C system library
Standard system math library
Compiler temporary files
File produced for analysis by prof(1)
File produced for analysis by gprof(1)
Fortran debugging support library
Fortran runtime library
System math library
Memory allocator for Oracle Developer Studio compilers and runtimes
Debugging support library for -xautopar and -xopenmp
Runtime library for -xautopar and -xopenmp
System vector math library
Runtime library for stack overflow diagnosis
System math library extensions
Sun Performance library
File access library for -xprofile
Linker audit library for -xprofile
Runtime library for -xprofile
System math lint library
System math lint library
System math extensions lint library
System math extensions lint library
The following reside in the Oracle Developer Studio installation directory, as indicated by <install-directory>.
Fortran preprocessor
C preprocessor
Path searched for f95 INCLUDE statement
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.
f95 support intrinsics. On Oracle Solaris, the shared library libfsu.so is bundled with the operating system.
Legacy f95 UNIX interface library
Legacy Fortran 95 array intrinsics libraries
Fortran 95 interval array intrinsics library
Oracle Developer Studio math library. On Oracle Solaris, the shared library libsunmath.so is bundled with the operating system.
Oracle Developer Studio interval math library
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’s 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
Oracle Developer Studio 12.6: Performance Library User’s Guide: The Oracle Developer Studio Performance Library contains 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
The diagnostics produced by f95 itself are intended to be self-explanatory. Occasional messages can be produced by the linker.