Man Page f95.1




NAME

     f95, f90 -	Fortran	95 compiler


SYNOPSIS

     May be invoked by either f95 or f90 commands; they	are
     equivalent.

     f95 [ -aligncommon[=a] ] [	-ansi ]	[ -arg=local ]
	  [ -autopar ] [ -Bx ] [ -C ] [	-c ] [ -cg89 ] [ -cg92 ]
	  [ -copyargs ]	[ -Dnm[=def] ] [ -dalign ]
	  [ -dbl_align_all[={yes|no}] ]	[ -depend[={yes|no}] ]
	  [ -dryrun ] [	-d{y|n}	] [ -e ] [ -erroff[=taglist] ]
	  [ -errtags[={yes|no}]	] [ -errwarn[=taglist] ]
	  [ -ext_names=e ] [ -F	] [ -f ]
	  [ -f77[=list]	] [ -fast ] [ -fixed ] [ -flags	]
	  [ -fma={none|fused} ]	[ -fnonstd ] [ -fns[={yes|no}] ]
	  [ -fpover[={yes|no}] ] [ -fpp	] [ -fprecision=p ]
	  [ -free ] [ -fround=r	] [ -fsimple[=n] ] [ -fstore ]
	  [ -ftrap=t ] [ -G ] [	-g ]
	  [ -hnm ] [ -help ] [ -Ipath ]	[ -inline=rl ]
	  [ -iorounding[=r] ] [	-keeptmp ] [ -KPIC ] [ -Kpic ]
	  [ -Lpath ] [ -lx ] [ -libmil ] [ -loopinfo ] [ -Mpath	]
	  [ -m32|-m64 ]	[ -moddir=path ] [ -mt ]
	  [ -native ] [	-noautopar ] [ -nodepend ]
	  [ -nofstore ]	[ -nolib ]
	  [ -nolibmil ]	[ -noreduction ] [ -norunpath ]
	  [ -O[n] ] [ -o nm ] [	-onetrip ]
	  [ -openmp[=a]	] [ -PIC ] [ -p	]
	  [ -pad[=a] ] [ -pg ] [ -pic ]
	  [ -Qoption pr	ls ] [ -qp ] [ -R list ] [ -r8const ]
	  [ -recl=a[,b]	] [ -reduction ] [ -S ]	[ -s ]
	  [ -silent ] [	-stackvar ] [ -stop_status={yes|no} ]
	  [ -temp=path ] [ -time ] [ -traceback[=list] ]
	  [ -U ] [ -Uname ] [ -u ]
	  [ -unroll=n ]	[ -use=list ] [	-V ] [ -v ] [ -vax=v ]
	  [ -vpara ] [ -w[n] ] [ -Xlist[z] ]
	  [ -xaddr32[={no|yes}]	] [ -xalias[=a[,a]...] ]
	  [ -xannotate[={yes|no}] ] [ -xarch=a ]
	  [ -xassume_control[=a[,a]...]	]
	  [ -xautopar ]	[ -xbinopt={prepare|off} ]
	  [ -xcache=c ]	[ -xcg89 ] [ -xcg92 ]
	  [ -xcheck=v ]	[ -xchip=c ] [ -xcode=v	]
	  [ -xcommonchk[={no|yes}] ] [ -xcrossfile=n ]
	  [ -xdebugformat={stabs|dwarf}	] [ -xdepend ]
	  [ -xdryrun ] [ -xF ]
	  [ -xfilebyteorder=options ]
	  [ -xhasc[={yes|no}] ]	[ -xhelp=h ]
	  [ -xhwcprof[=e] ] [ -xia[=i] ]
	  [ -xinline=rl	] [ -xinstrument=d ] [ -xinterval=i ]
	  [ -xipo[=n] ]	[ -xipo_archive=a ]
	  [ -xivdep[=p]	] [ -xjobs=n ] [ -xkeepframe[=p] ]
	  [ -xknown_lib=lib ] [	-xl ] [	-xld ] [ -xlang=f77 ]
	  [ -xlibmil ] [ -xlibmopt ] [ -xlicinfo ]
	  [ -xlic_lib=sunperf ]	[ -xlinkopt[=level] ]
	  [ -xloopinfo ] [ -xmaxopt[=n]	]
	  [ -xmemalign[=ab] ] [	-xmodel=[a] ] [	-xnolib	]
	  [ -xnolibmil ] [ -xnolibmopt ] [ -xO[n] ]
	  [ -xopenmp[=a] ] [ -xpad[=a] ] [ -xpagesize=n	]
	  [ -xpagesize_heap=n ]	[ -xpagesize_stack=n ]
	  [ -xpec[={yes|no}] ] [ -xpg ]	[ -xpp=p ]
	  [ -xprefetch=a[,a]]
	  [ -xprefetch_auto_type=[no%]indirect_array_access ]
	  [ -xprefetch_level=n ]
	  [ -xprofile=p	] [ -xprofile_ircache=path ]
	  [ -xrecursive	] [ -xreduction	] [ -xregs=r ] [ -xs ]
	  [ -xsafe=mem ]
	  [ -xspace ] [	-xtarget=t ] [ -xtime ]
	  [ -xtypemap=spec ] [ -xunroll=n ]
	  [ -xvector[={v}] ] [ -xvpara ] [ -ztext ]
	    source file(s) ...	[ -lx ]



DESCRIPTION

     Oracle Solaris Studio 12.2	Fortran	95 compiler, version 8.5

     The f95 compiler accepts standard-compliant Fortran 95
     source code programs. It also accepts some	Fortran	2003
     features, extensions for interval arithmetic, and the
     OpenMP[tm]	Fortran	95 API version 3.0.  It	also accepts many
     FORTRAN 77	(f77) language extensions under	the -f77
     compatibility option, and VAX VMS Fortran extensions (-vax).

     Version 8.5  of the Fortran 95 compiler f95 is released as	a
     component of Oracle Solaris Studio	12.2, and is available
     for the Solaris[tm] Operating System (Solaris OS) version
     10, on SPARC(R) and x86 platforms,	on OpenSolaris x86
     platforms,	and on Linux x86 platforms.

     For the latest important information on platforms,
     environments, new features, limitations, problems,
     workarounds, and software corrections, see	the documentation
     on	the Solaris Studio web portal at
     http://developers.sun.com/sunstudio/.

     A man page, by definition,	is a quick  reference.	For more
     detailed information on using the f95 compiler and	its
     options, see the Fortran User Guide and the Fortran
     Programming Guide.	These manuals can be accessed from the
     documentation pages on the	Solaris	Studio portal





     http://developers.sun.com/sunstudio/

     See the Fortran User's Guide for complete details on how to
     use the f95 compiler. The user guide details all the
     options, pragma directives, and environment variables
     accepted by f95, and describes any	differences between
     standard Fortran 95 and this Fortran 95 compiler.

     See the Fortran Programming Guide for information on program
     performance and optimization, parallelization, and	porting
     from other	Fortran	platforms.

     A list of relevant	Solaris	Studio documentation appears at
     the end of	this man page.

     An	index to all the installed Solaris Studio documentation,
     including links to	documentation on the Solaris Studio
     portal, can be found on the Solaris Studio	portal at
	http://developers.sun.com/sunstudio

     Additional	information, including technical articles and
     latest news about patches and workarounds,	can be found on
     the developer resources portal at
     http://developers.sun.com/sunstudio/


COMPILING FOR 64-BIT PLATFORMS:

     The way to	specify	compilation of a 32-bit	or 64-bit binary
     has changed in this release. The -xarch option no longer
     carries an	implicit memory	model, 32-bit ILP32 or 64-bit
     LP64, with	each definition, and is	now used only to specify
     the instruction set of the	target processor.

     Use the new -m32 and -m64 options to specify the memory
     model of the target compilation.

     The ILP32 model specifies that C-language int, long, and
     pointer data types	are all	32-bits	wide. The LP64 model
     specifies that long and pointer data types	are all	64-bits
     wide. The Solaris and Linux OS also support large files and
     large arrays under	the LP64 memory	model.

     When compiling with -m64, the resulting executable	will work
     only on 64-bit UltraSPARC(R) or x86 processors under Solaris
     OS	or Linux OS running a 64-bit kernel. Compilation,
     linking, and execution of 64-bit objects can only take place
     in	a Solaris or Linux OS that supports 64-bit execution.


SPECIAL x86 NOTES

     There are some important issues to	be aware of when
     compiling for x86 Solaris platforms.

     Programs compiled with -xarch set to sse,	sse2, sse2a, or
     sse3 must be run only on platforms	that provide these
     extensions	and features.

     If	you compile and	link in	separate steps,	always link using
     the compiler and with same	-xarch setting to ensure that the
     correct startup routine is	linked.

     Numerical results on x86 might differ from	results	on SPARC
     due to the	x86 80-bit floating-point registers. To	minimize
     these differences,	use the	-fstore	option or compile with
     -xarch=sse2 if the	hardware supports SSE2.

     Numerical results can also	differ between Solaris and Linux
     because the intrinsic math	libraries (for example,	sin(x))
     are not the same.

     Binary Compatibility Verification
     Starting with Sun Studio 11 and the Solaris 10 OS,	program
     binaries compiled and built using these specialized -xarch
     hardware flags are	verified that they are being run on the
     appropriate platform.

     On	systems	prior to Solaris 10, no	verification is	done and
     it	is the user's responsibility to	ensure objects built
     using these flags are deployed on suitable	hardware.

     Running programs compiled with these -xarch options on
     platforms that are	not enabled with the appropriate features
     or	instruction set	extensions could result	in segmentation
     faults or incorrect results occurring without any explicit
     warning messages.

     This warning extends also to programs that	employ .il inline
     assembly language functions or __asm() assembler code that
     utilize SSE, SSE2,	SSE2a, and SSE3	instructions and
     extensions.


OPTIONS

     Options valid only	on SPARC platforms are marked (SPARC).

     Options valid only	on x86/x64 platforms are marked	(x86).

     Deprecated	options	are marked (Obsolete) and should not be
     used going	forward. They are provided only	for compatibility
     with earlier releases. Use	the indicated replacement option.

     See ld(1) for linker options.

     f95 compiles "silently". Except for error and warning
     messages, it does not issue "progress" messages during
     compilation.

     In	general, processing of the compiler options is from left
     to	right, permitting selective overriding of macro	options.
     This rule does not	apply to linker	or preprocessor	options.

     In	the syntax of the command-line options,	items shown in
     square brackets ( [] ) are	optional. Curly	brackets enclose
     a bar-separated list of literal items to be chosen, as in
     {yes | no | maybe } .  The	first item in a	list usually
     indicates the default value when the flag appears without a
     value.

     For example, -someoption[={no|yes}] implies -someoption is
     the same as -someoption=no	.



LIST OF OPTIONS

     -aligncommon[={1|2|4|8|16}]
	  Specify alignment of data in common blocks and standard
	  numeric sequence types.

	  The value specified indicates	the maximum alignment (in
	  bytes) for data elements within common blocks	and
	  standard numeric sequence types. For example,
	  -aligncommon=4 would align common block data elements
	  with natural alignments of 4 bytes or	more on	4-byte
	  boundaries.  This option does	not affect data	with
	  natural alignment smaller than the specified size.

	  The default, when -aligncommon is not	specified, aligns
	  common block and standard numeric sequence data on at
	  most 4-byte boundaries.

	  Specifying -aligncommon without a value defaults to 1
	  on all platforms: All	data aligns on byte boundaries
	  (no padding between elements).

	  -aligncommon=16 reverts to -aligncommon=8 when
	  compiling for	platforms that are not 64-bit enabled.

	  Using	-aligncommon=1 on SPARC	platforms might	result in
	  a bus	error due to misalignment, requiring an
	  appropriate choice of	the -xmemalign option be used.
	  Depending on the application,	-xmemalign=1s, -
	  xmemalign=4ior -xmemalign=8i should give optimal
	  performance while avoiding the segmentation fault.

	  See also -xmemalign

     -ansi
	  Identify nonstandard extensions.

     -arg=local

	  Preserve actual arguments over ENTRY statements.

	  When you compile a subprogram	with alternate entry
	  points with this option, f95 uses copy restore to
	  preserve the association of dummy and	actual arguments.

	  This option is provided for compatibility with legacy
	  Fortran 77 programs.	Code that relies on this option
	  is nonstandard.

     -autopar
	  Enable automatic loop	parallelization

	  Find and parallelize appropriate loops. Do dependence
	  analysis (analyze loops for data dependences). Do loop
	  restructuring.  If optimization is not -O3 or	higher,
	  it is	raised to -O3.

	  Also specify the -stackvar option when using any of the
	  parallelization options.  The	-stackvar option may
	  provide better performance when using	-autopar because
	  it may allow the optimizer to	detect additional
	  opportunities	for parallelization.  See the description
	  of the -stackvar option for information on how to set
	  the sizes for	the main thread	stack and for the slave
	  thread stacks.

	  Avoid	-autopar if you	do your	own thread management.
	  See note under -mt.

	  Also,	-autopar is inappropriate on a single-processor
	  system, and will degrade performance.

	  For more information,	see the	Parallelization	chapter
	  in the Fortran Progamming Guide.

	  Number of Threads:  To run a parallelized program in a
	  multithreaded	environment, you must set the
	  OMP_NUM_THREADS environment variable prior to
	  execution. This variable tells the runtime system the
	  maximum number of threads the	program	can create. The
	  default is 1.	 In general, set OMP_NUM_THREADS to the
	  available number of virtual processors on the	running
	  system, which	can be determined by using the Solaris
	  psrinfo(1) command.

	  If you use -autopar and compile and link in one step,
	  linking will automatically include the microtasking
	  library and the threads-safe Fortran runtime library.
	  If you use -autopar and compile and link in separate
	  steps, then you must link with f95 -autopar as well.

     -B{dynamic|static}
	  Prefer dynamic or require static library linking.

	  Indicates that either	dynamic	library	linking	is
	  preferred, or	static linking required	for any	libraries
	  listed later in the command.	This is	a linker option.

	  The default is -Bdynamic.

	  -Bdynamic:  Prefer dynamic linking (shared libraries)
	  -Bstatic :  Require static linking (no shared
	  libraries)

	  If you specify static	but the	linker finds only a
	  dynamic library, then	the library is not linked and a
	  warning issued.

	  However, if you specify dynamic but the linker finds
	  only a static	version, that library is linked	with no
	  warning.

	  You can toggle between -Bdynamic and -Bstatic	on the
	  command line,	linking	some libraries statically and
	  others dynamically.

	  Because these	are linker options, compiling with -
	  Bstatic or -Bdynamic requires	the same options on a
	  linker command if done in separate steps.

	  In a 64-bit environment, many	system libraries are
	  available only as shared dynamic libraries. These
	  include libm.so and libc.so (libm.a and libc.a are not
	  provided). As	a result, -Bstatic and -dn can cause
	  linking errors in 64-bit Solaris OS. Applications must
	  link with the	dynamic	libraries in these cases.

	  Note:	Mixing static Fortran runtime system libraries
	  with dynamic Fortran runtime system libraries	is not
	  recommended and can result in	linker errors or silent
	  data corruption.  Always link	with the latest	shared
	  dynamic Fortran runtime system libraries.

     -C	  Check	array references for out of range subscripts and
	  conformance.

	  Arrays subscripted beyond their declared sizes can
	  result in unexpected results,	including segmentation
	  faults. The -C option	checks for possible array
	  subscript violations in the source code and during
	  execution.

	  With the -C option specified,	run-time array subscript
	  violations are treated as an error. The compiler will
	  also flag array subscript range violations in	the
	  source code as warnings.

	  Compiling with -C also adds checks for array
	  conformance at runtime in statements using array
	  syntax.

	  This option will increase the	size of	the executable
	  file and degrade execution performance.  It should only
	  be used while	debugging.

     -c	  Compile only,	do not make executable file.

	  Compile and produce a	.o file	for each source	file but
	  suppress linking by the loader.  You can name	a single
	  object file explicitly using the -o option.

     -cg89
	  (Obsolete, SPARC) Generate code for generic SPARC
	  architecture

	  This option is a macro for:
	     -xarch=v7 -xchip=old -xcache=64/32/1
	  and is equivalent to:	  -xtarget=ss2	 This option
	  should not be	used. Current Solaris operating	systems
	  no longer support SPARC V7 architecture. Compiling with
	  this option will generate code that will run slower on
	  current SPARC	platforms.  This feature might not be
	  supported in later versions of the compiler.

     -cg92
	  (Obsolete, SPARC) Generate code for SPARC V8
	  architecture

	  This option is a macro for:
	  -xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1.
	  and is equivalent to:	    -xtarget=ss1000

	  This feature might not be supported in later versions
	  of the compiler.

     -copyargs
	  Allow	assignment to constant arguments.

	  Allow	a subprogram to	change a dummy argument	that is	a
	  constant. This option	is provided only to allow legacy
	  code to compile and execute without a	runtime	error for
	  changing a constant.

	  Without -copyargs, if	you pass a constant argument to	a
	  subroutine, and then within the subroutine try to
	  change that constant,	the run	gets a runtime error.

	  With -copyargs, if you pass a	constant argument to a
	  subroutine, and then within the subroutine change that
	  constant, the	run does not necessarily get a runtime
	  error.

	  Programs that	require	compilation with the -copyargs
	  flag are not Fortran standard-compliant.

     -Dname[=def]
	  Define symbol	name for the source code preprocessor.

	  This is equivalent to	a #define directive in the
	  source. If no	def is given, name is defined as 1. This
	  option applies to .F .F90 .F95 .F03 suffix files only.

	  The following	symbols	are predefined on appropriate
	  systems; note	the two	leading	underscores:

	     __sparc, __sparcv9, __unix, __sun,	__i386,	__x86_64,
	     __amd64, __SVR4, __SunOS_5_6, __SunOS_5_7,
	     __SunOS_5_8, __SunOS_5_9, __SunOS_5_10

	  Fortran syntax might not support the actual values of
	  these	symbols--they should appear only on fpp	or cpp
	  preprocessor statements, such	as conditionals:
	     #ifdef __sparc

	  Corresponding	older values (prior releases) are:
	      sparc, unix, sun,

	  These	earlier	predefined values might	be deleted in a
	  future release.

	  f95 uses the fpp(1) preprocessor by default. Like the	C
	  preprocessor cpp(1), fpp expands source code macros and
	  enables conditional compilation of code. Unlike cpp,
	  fpp understand Fortran syntax, and is	preferred as a
	  Fortran preprocessor.	Use the	-xpp=cpp flag to force
	  the compiler to specifically use cpp rather than fpp.

     -dalign
	  Align	COMMON blocks and standard numeric sequence types
	  and generate faster multi-word load/stores.

	  This flag changes the	data layout in COMMON blocks (and
	  EQUIVALENCE classes),	and enables the	compiler to
	  generate faster multi-word load/stores for that data.

	  -dalign is a macro equivalent	to
	    -xmemalign=8s -aligncommon=16 on SPARC platforms,
	    -aligncommon=8 on 32-bit x86 platforms, and
	    -aligncommon=16 on 64-bit x86 platforms.

	  The data layout effect is that of the	-f flag: double-
	  and quad-precision data in COMMON blocks and
	  EQUIVALENCE classes are laid out in memory along their
	  "natural" alignment, which is	on 8-byte boundaries (or
	  16-byte boundaries for quad-precision	when compiling
	  for 64-bit platforms with -m64.)  The	default	alignment
	  in COMMON blocks is on 4-byte	boundaries.

	  Using	-dalign	along with
	  -xtypemap=real:64,double:64,integer:64 also causes 64-
	  bit integer variables	to be double-word aligned on
	  SPARC.

	  Using	-dalign, can result in nonstandard FORTRAN
	  alignment which could	cause problems with variables in
	  EQUIVALENCE or COMMON	and can	render the program non-
	  portable if -dalign is required.

	  If you compile one subprogram	or file	with -dalign,
	  then all subprograms and files in the	program	unit must
	  be compiled with -dalign.

	  Because -dalign invokes -aligncommon,	the alignment of
	  standard numeric sequence types is also affected.

	  The -fast flag selects -dalign.

     -dbl_align_all[={yes|no}]
	  Force	alignment of data on 8-byte boundaries.

	  If yes all variables will be aligned on 8-byte
	  boundaries. Default is -dbl_align_all=no. By itself,
	  -dbl_align_all is equivalent to -dbl_align_all=yes.

	  When compiling for 64-bit SPARC environments with -m64,
	  this flag will align quad-precision data on 16-byte
	  boundaries.

	  This flag does not alter the layout of data in COMMON
	  blocks or user-defined structures.

	  If used, all routines	must be	compiled with this
	  option.

     -depend[=yes|no]
	  Analyze loops	for data dependence and	restructuring.

	  -depend is equivalent	to -depend=yes and enables loop
	  dependence analysis.	It is on by default on all
	  platforms.

	  -depend=no disables DO loop data dependence analysis

     -dryrun
	  Show commands	built by the f95 driver	but do not
	  compile.

	  Useful when debugging, this option displays the
	  commands the compiler	will run to perform the
	  compilation.

     -d{y|n}
	  Allow/disallow dynamic libraries for executable

	  Allow	or disallow dynamic libraries for the entire
	  executable. This flag	is a linker option.

	  The default is -dy.

	  -dy:	Allow dynamic libraries.
	  -dn:	Do not allow dynamic libraries.

	  Unlike -B{dynamic|static}, this option applies to the
	  whole	executable and need appear only	once on	the
	  command line.

	  -d{y|n} are linker options. If you compile and link in
	  separate steps with these options, then you need the
	  same option in the final link	step.

	  In a 64-bit environment, many	system libraries are
	  available only as shared dynamic libraries. These
	  include libm.so and libc.so (libm.a and libc.a are not
	  provided). As	a result, -Bstatic and -dn can cause
	  linking errors in 64-bit Solaris OS platforms	and 32-
	  bit Solaris x86 platforms and	all 32-bit Solaris
	  platforms starting with the Solaris 10 release.
	  Applications must link with the dynamic libraries in
	  these	cases.

     -e	  Extend source	line maximum length to 132 characters.

	  The compiler pads on the right with trailing blanks to
	  column 132.  If you use continuation lines while
	  compiling with -e, then do not split character
	  constants across lines, otherwise unnecessary	blanks
	  might	be inserted in the constants.

     -erroff[={%all|%none|taglist}]
	  Suppress warning messages listed by tag name.

	  This option only affects warning messages. Error
	  messages are not affected.  The taglist specifies a
	  list of comma-separated tag names that appear	with
	  warning messages. If just %all is specified, all
	  warnings are suppressed (this	is equivalent to the -w
	  option.) If just %none is specified, no warnings are
	  suppressed.  -erroff specified without a value is
	  equivalent to	-erroff=%all.

	  (See also -errtags.)

     -errtags[={yes|no}]
	  Display the message tag with each warning message.

	  The compiler's internal error	tag name appears along
	  with error messages. The default is not to display the
	  tag (-errtags=no). The second	default	(-errtags without
	  a value) is -errtags=yes.

     -errwarn[={%all|%none|taglist}]
	  Treat	warning	messages as errors.

	  The taglist specifies	a list of comma-separated tag
	  names	of warning messages that should	be treated as
	  errors. If just %all is specified, all warnings are
	  treated as errors.  If just %none is specified, no
	  warnings are treated as errors.

	  See also -errtags.

     -ext_names=e
	  Create external names	with or	without	underscores.

	  e must be plain or underscores or fsecond-underscore.
	  The default is underscores.

	  plain
	  Do not use trailing underscores.

	  underscores
	  Use trailing underscores.

	  fsecond-underscore
	  Append two underscores to external names that	contain
	  an underscore, and a single underscore to those that do
	  not.

	  An external name is a	name of	a subroutine, function,
	  block	data subprogram, or labeled common.  This option
	  affects both the name	in the routine itself and, of
	  course, the name used	in the calling statement (both
	  symdefs and symrefs).
	  fsecond-underscore is	provided for compatibility with
	  gfortran.

     -F	  Invoke the source file preprocessor, but do not compile

	  Apply	the fpp	preprocessor to	.F90, .F95, .F03, and .F
	  files	and put	the result in the file with the	suffix
	  changed to .f90, .f95, .f03,or .f, but do not	compile.

	  fpp is the default preprocessor for Fortran. The C
	  preprocessor,	cpp, can be selected instead by
	  specifying -xpp=cpp.

     -f	  Align	double-	and quad-precision data	in COMMON blocks.

	  This flag changes the	data layout in COMMON blocks (and
	  EQUIVALENCE classes):	double-	and quad-precision data
	  in COMMON blocks and EQUIVALENCE classes are laid out
	  in memory along their	"natural" alignment, which is on
	  8-byte boundaries (or	on 16-byte boundaries for quad-
	  precision when compiling for 64-bit environments with
	  -m64). The default alignment of data in COMMON blocks
	  is on	4-byte boundaries.

	  -f is	equivalent to -aligncommon=16.

	  This option applies to both real and complex data.

	  Resulting code might not be standard and might not be
	  portable.

	  If you compile one subprogram	with -f, compile all
	  subprograms of the program with -f.

	  By itself, this option does not enable the compiler to
	  generate faster double word fetch/store instructions
	  and double and quad precision	data. Only -dalign will
	  do this.


     -f77[=list]
	  Select Fortran 77 compatibility mode.

	  list is a comma-separated list selected from the
	  following possible keywords:

	  %all	  Select all the f77 compatibility features.

	  %none	  Disable the f77 compatibility	features.

	  output  Generate f77-style formatted output, including
		  list-directed	and namelist output.

	  input	  Accept input formats allowed by f77.

	  tab	  Enable f77-style TAB-formatting, including
		  unlimited source line	length.	Also, no blank
		  padding will be added	to source lines	shorter
		  than 72 characters.

	  backslash
		  Accept a backslash character as the beginning
		  of an	escape sequence	in character strings.

	  intrinsics
		  Limit	recognition of intrinsics to only Fortran
		  77 intrinsics.

	  logical Accept Fortran 77 usage of logical variables,
		  such as:

		  - Allow assignment of	integer	values to logical
		    variables.

		  - Allow arithmetic expressions in place of
		    logical expressions	in conditional
		    statements,	with .NE.0 representing	.TRUE..

		  - Allow use of relational operators .EQ. and
		    .NE. with logical operands.

	  subscript
		  Allow	non-integer expressions	as array
		  subscripts.

	  misc	  Allow	other miscellaneous Fortran 77 extensions
		  not supported	by Fortran 95.

	  All keywords can be prefixed by no% to disable the
	  corresponding	feature, as in:

	     -f77=%all,no%backslash

	  The default, when -f77 is not	specified is -f77=%none.
	  When -f77 is used without a list, it is equivalent to
	  -f77=%all.

	  Trapping on Exceptions
	  Specifying -f77 does not change the Fortran 95 trapping
	  mode,	which is -ftrap=common.	 Fortran 95 differs from
	  the Fortran 77 compiler's behavior regarding arithmetic
	  exception trapping, which was	to allow execution to
	  continue after arithmetic exceptions.	It also	made the
	  program call ieee_retrospective on program exit to
	  report on any	arithmetic exceptions that occurred
	  during execution.  Specify -ftrap=%none after	-f77 to
	  revert to trapping that mimics Fortran 77's behavior.

	  Migrating FORTRAN 77 Programs	to Fortran
	  See the chapter on FORTRAN 77	compatibility in the
	  Fortran User's Guide for details on -f77 and the
	  compatibility	features it provides. See also the
	  -xalias flag for handling nonstandard	FORTRAN	77
	  programming that can cause incorrect results.

	  Compile with f77
	  A Fortran 77 compiler	script has been	provided for
	  convenience. The f77 command-line script invokes the
	  f95 compiler with the	appropriate set	of options for
	  Fortran 77 compatibility. See	the f77(1) man page for
	  details.

     -fast
	  Select options that optimize execution performance.

	  -fast	provides high performance for certain
	  applications.	 However, the particular choice	of
	  options might	not be appropriate for your application.
	  Use -fast as a good starting point for compiling your
	  application for best performance. But	additional tuning
	  might	still be required. If your program behaves
	  improperly when compiled with	-fast, look closely at
	  the individual options that make up -fast and	invoke
	  only those appropriate to your program that preserve
	  correct behavior.

	  Note also that a program compiled with -fast might show
	  good performance and accurate	results	with some data
	  sets,	but not	with others. Avoid compiling with -fast
	  those	programs that depend on	particular properties of
	  floating-point arithmetic.

	  -fast	selects	the following options:

	  o -xtarget=native sets the hardware target.
	    If the program is intended to run on a different
	    target than	the compilation	machine, follow	the -fast
	    with the appropriate -xtarget= option. For example:
		  f95 -fast -xtarget=generic ...

	  o -O5	selects	optimization level 5.

	  o -libmil selects inlining of	certain	math library
	    routines.

	  o -fsimple=2 selects aggressive floating-point
	    optimizations. This	option might be	unsuited for
	    programs requiring strict IEEE 754 standards
	    compliance.

	  o -dalign selects generation of faster double	word
	    load/store instructions, and alignment of double and
	    quad data on their natural boundaries in common
	    blocks.  Using this	option might generate nonstandard
	    Fortran data alignment.

	  o -xlibmopt selects linking the optimized math library.
	    (Solaris only)

	  o -depend=yes	selects	dependence analysis to better
	    optimize DO	loops.	(This option is	always selected
	    for	optimization levels -O3	and greater.)

	  o -fns selects faster	(but nonstandard) handling of
	    floating-point arithmetic exceptions and gradual
	    underflow.

	  o -ftrap=common selects trapping on common floating-
	    point exceptions (this is the default for f95).

	  o -pad=local selects local padding to	improve	use of
	    cache.  (SPARC)

	  o -xvector=lib selects the vectorized	math library.
	    (SPARC)

	  o -fround=nearest is selected	because	-xvector and
	    -xlibmopt require it.  (Solaris only)

	  o -nofstore cancels forcing expressions to have the
	    precision of the result.  (x86)

	  o -xregs=frameptr on x86 allows the compiler to use the
	    frame-pointer register as a	general-purpose	register.
	    Be sure to read the	discussion of -xregs=frameptr
	    especially when compiling mixed C, Fortran,	and C++
	    source codes.  Specify -xregs=no%frameptr after -fast
	    and	the frame pointer register will	not be used as a
	    general purpose register.  (x86)

	  Note that this selection of component	option flags is
	  subject to change with each release of the compiler.
	  For details on the options set by -fast, see the
	  Fortran User's Guide.

	  To determine the expansion of	-fast on a running
	  system, execute the command

	  f95 -fast -dryrun |& grep ###
	  It is	possible to add	or subtract from this list by
	  following the	-fast option with other	options, as in:
	       f95 -fast -fsimple=1 -xnolibmopt
	  which	overrides the -fsimple=2 flag and disables the
	  -xlibmopt selected by	-fast.

	  Because -fast	selects
	       -dalign -fns -fsimple=2
	  programs compiled with this option can result	in
	  nonstandard floating-point arithmetic, nonstandard
	  alignment of data, and nonstandard ordering of
	  expression evaluation. These selections might	not be
	  appropriate for most programs.

	  Also,	because	-fast selects -xlibmopt	and -xvector=lib,
	  default rounding mode, -fround=nearest, is assumed and
	  required when	using -fast.

	  For separate compile and link	steps: if you compile
	  with -fast, then be sure to link with	-fast.

     -fixed
	  Assume fixed-format source input.

	  Interpret all	source files as	Fortran	95 fixed-format.
	  Overrides the	file suffix.

     -flags
	  Synonym for -help.

     -fma={none|fused}
	  (SPARC) Enable automatic generation of floating-point,
	  fused, multiply-add instructions. -fma=none disables
	  generation of	these instructions.  -fma=fused	allows
	  the compiler to attempt to find opportunities	to
	  improve the performance of the code by using floating-
	  point, fused,	multiply-add instructions.

	  The default is -fma=none.

	  Minimum requirements are -xarch=sparcfmaf and	an
	  optimization level of	at least -xO2 for the compiler to
	  generate fused multiply-add instructions. The	compiler
	  will mark the	binary program if fused	multiply-add
	  instructions have been generated to prevent execution
	  of the program on platforms that do not support them.

	  Fused	multiply-adds eliminate	the intermediate rounding
	  step between the multiply and	the add.  Consequently,
	  programs may produce different results when compiled
	  with -fma=fused, although precision will tend	to be
	  increased rather than	decreased.
     -fnonstd
	  Initialize floating-point hardware to	nonstandard
	  preferences

	  This option is a macro for the combination
		 -fns -ftrap=common
	  which	initializes the	floating-point hardware	to:

	  o  Abort on exceptions
	  o  Flush denormalized	numbers	to zero	if it will
	  improve speed

	  To be	effective, compile the main program with this
	  flag.

	  See -fns for a information on	underflow and handling of
	  denormalized numbers.

	  The -fnonstd option enables hardware traps for
	  floating-point overflow, division by zero, and invalid
	  operation exceptions.	These are converted into SIGFPE
	  signals, and if the program has no SIGFPE handler, it
	  aborts. See ieee_handler(3m),	ieee_functions(3m), the
	  Numerical Computation	Guide, and Fortran Programming
	  Guide	for more information.

     -fns[={yes|no}]
	  Select nonstandard floating point

	  The default, -fns=no,	utilizes standard floating-point
	  mode.

	  Optional use of =yes or =no provides a way of	toggling
	  the -fns flag	following some other macro flag	that
	  includes -fns, such as -fast.

	  -fns is the same as -fns=yes.
	  -fns=yes selects nonstandard floating-point.
	  -fns=no selects standard floating-point. (Default)

	  -fast	selects	-fns.

	  On SPARC platforms, nonstandard floating point mode
	  disables "gradual underflow",	causing	tiny results to
	  be flushed to	zero rather than producing subnormal
	  numbers.  It also causes subnormal operands to be
	  silently replaced by zero.  On those SPARC platforms
	  that do not support gradual underflow	and subnormal
	  numbers in hardware, use of this option can
	  significantly	improve	the performance	of some	programs.

	  On x86 platforms, this option	is enabled only	for
	  Pentium III and Pentium 4 processors (sse or sse2).

	  On x86, -fns selects SSE flush-to-zero mode and where
	  available, denormals-are-zero	mode.  This flag causes
	  subnormal results to be flushed to zero.  Where
	  available, this flag also causes subnormal operands to
	  be treated as	zero.

	  This flag has	no effect on traditional x87 floating-
	  point	operations not utilizing the SSE or SSE2
	  instruction set.

	  Warning: When	nonstandard mode is enabled, floating
	  point	arithmetic can produce results that do not
	  conform to the requirements of the IEEE 754 standard.
	  See the Numerical Computation	Guide and the Fortran
	  User's Guide for more	information.

	  This option is effective only	if used	when compiling
	  the main program.

     -fpover[={yes|no}]
	  Detect floating-point	overflow in formatted input.

	  With -fpover=yes specified, the I/O library will detect
	  floating-point overflows in formatted	input and cause
	  an arithmetic	exception. Combine with	-ftrap to get
	  full diagnostic information.

	  The default is no such overflow detection (-fpover=no).
	  -fpover is equivalent	to -fpover=yes.

     -fpp Force	preprocessing of input files with fpp.

	  Pass all the input source files listed on the	command
	  line through the fpp preprocessor, regardless	of file
	  extension. (Files with .F90, .F95, .F, F03, extension
	  are automatically preprocessed by fpp. See also -xpp.)

     -fprecision=p
	  (x86)	Initialize non-default floating-point rounding
	  precision mode.

	  On x86, sets the floating-point precision mode to
	  either single, double, or extended.

	  When p is single or double, this flag	causes the
	  rounding precision mode to be	set to single or double
	  precision respectively at program initiation.	 When p
	  is extended or the -fprecision flag is not used, the
	  rounding precision mode is initialized to extended
	  precision.
	  This option is effective only	on x86 systems and only
	  if used when compiling the main program, but is ignored
	  if compiling for 64-bit platforms (-m64), or SSE2-
	  enabled processors (-xarch=sse2).  -fprecision is
	  ignored on SPARC platforms.

     -free
	  Assume free-format source input.

	  Interpret all	source files as	Fortran	95 free-format.
	  Overrides the	file suffix.

     -fround=r
	  Select the IEEE rounding mode	in effect at startup.

	  r must be one	of:
		nearest, tozero, negative, positive.

	  The default is -fround=nearest.

	  When r is tozero, negative, or positive this flag
	  causes the rounding direction	mode to	be set to round-
	  to-zero, round-to-negative-infinity, or round-to-
	  positive-infinity respectively when the program begins
	  execution.  When r is	nearest	or the -fround flag is
	  not used, the	rounding direction mode	is not altered
	  from its initial value (round-to-nearest by default).

	  This option is effective only	if used	when compiling
	  the main program.

	  Note that compiling with -xvector or -xlibmopt require
	  default rounding. Programs that link with libraries
	  compiled with	either -xvector	or -xlibmopt or	both must
	  ensure that default rounding is in effect.

     -fsimple[=n]
	  Select floating-point	optimization preferences

	  Allow	the optimizer to make simplifying assumptions
	  concerning floating-point arithmetic.

	  If n is present, it must be 0, 1, or 2.

	  The defaults are:
	     With no -fsimple, f95 uses	-fsimple=0
	     With only -fsimple, f95 uses -fsimple=1

	  -fsimple=0
	     Permit no simplifying assumptions.	Preserve strict
	     IEEE 754 conformance.

	  -fsimple=1
	     Allow conservative	simplifications. The resulting
	     code does not strictly conform to IEEE 754, but
	     numeric results of	most programs are unchanged.

	     With -fsimple=1, the optimizer can	assume the
	     following:

		IEEE 754 default rounding/trapping modes do not
		change after process initialization.

		Computations producing no visible result other
		than potential floating	point exceptions might be
		deleted.

		Computations with Infinity or NaNs as operands
		need not propagate NaNs	to their results; e.g.,
		x*0 might be replaced by 0.

		Computations do	not depend on sign of zero.

	     With -fsimple=1, the optimizer is not allowed to
	     optimize completely without regard	to roundoff or
	     exceptions. In particular,	a floating-point
	     computation cannot	be replaced by one that	produces
	     different results with rounding modes held	constant
	     at	run time.

	  -fsimple=2

	     In	addition to -fsimple=1,	permits	aggressive
	     floating-point optimizations that can cause many
	     programs to produce different numeric results due to
	     changes in	rounding. Also,	enables	use of SIMD
	     instructions to compute reductions	when compiling
	     with -xvector=simd.

	     In	particular, the	Fortran	standard rule requiring
	     compilers to honor	explicit parentheses around
	     subexpressions to control expression evaluation
	     order might be broken with	-fsimple=2. This could
	     result in numerical rounding differences with
	     programs that depend on this rule.

	     For example, with -fsimple=2, the compiler	might
	     evaluate C-(A-B) as (C-A)+B, breaking the standard's
	     rule about	explicit parentheses, if the resulting
	     code is better optimized. The compiler might also
	     replace repeated computations of x/y with x*z, where
	     z=1/y is computed once and	saved in a temporary, to
	     eliminate the costly divide operations.

	     Programs that depend on particular	properties of
	     floating-point arithmetic should not be compiled
	     with -fsimple=2.

	     Even with -fsimple=2, the optimizer still tries not
	     to	introduce a situation that could produce a
	     floating-point exception in a program that	otherwise
	     produces none.

	     -fast selects -fsimple=2.

     -fstore
	  (x86)	Force precision	of floating-point expressions

	  For assignment statements, this option forces	all
	  floating-point expressions to	the precision of the
	  destination variable.	The default is -fstore.	 However,
	  the -fast option includes -nofstore to disable this
	  option. Follow -fast with -fstore to turn this option
	  back on.

     -ftrap=t
	  Set floating-point trapping mode

	  This option sets the IEEE floating-point trapping that
	  is in	effect at startup.

	  t is a comma-separated list that consists of one or
	  more of the following:

	   %all, %none,	common,	[no%]invalid, [no%]overflow,
	   [no%]underflow, [no%]division, [no%]inexact.

	  The f95 default is -ftrap=common.  (Note that	the
	  default with f77 was -ftrap=%none.)

	  This option the IEEE 745 trapping mode in effect at
	  startup but does not install a SIGFPE	handler. You can
	  use ieee_handler(3M) or fex_set_handling(3M) to
	  simultaneously enable	traps and install a SIGFPE
	  handler. If you specify more than one	value, the list
	  is processed sequentially from left to right.

	  Example: Set all traps except	inexact:

		-ftrap=%all,no%inexact

	  The meanings are the same as for the ieee_flags
	  function:

	  Value		 Meaning

	  [no%]division	 [Do not] Trap on division by zero.

	  [no%]inexact	 [Do not] Trap on inexact result.

	  [no%]invalid	 [Do not] Trap on invalid operation.

	  [no%]overflow	 [Do not] Trap on overflow.

	  [no%]underflow [Do not] Trap on underflow.

	  %all		 Trap on all the above.

	  %none		 Trap on none of the above.

	  common	 Trap on invalid, division by zero, and
			 overflow.


	  To be	effective this option must be used when	compiling
	  the main program.

     -G	  Build	a dynamic shared library

	  Direct the linker to make a shared dynamic library.
	  Without -G the linker	builds an executable file. With
	  -G it	builds a dynamic library (but no executable).
	  Use -o with -G to specify the	name of	the file to be
	  written.

	  For more information about dynamic libraries and how to
	  create them, see the Fortran Programming Guide.

     -g	  Compile for debugging	and performance	analysis.

	  Produce additional symbol table information for
	  debugging with dbx(1)	or the Studio Debugger,	and for
	  analysis with	the Studio Performance Analyzer,
	  analyzer(1).

	  Although some	debugging is possible without specifying
	  -g, the full capabilities of dbx are only available to
	  those	objects	compiled with -g.


	  To use the full capabilities of the Solaris Studio
	  Performance Analyzer,	compile	with -g.  While	some
	  performance analysis features	do not require -g, you
	  must compile with -g to view annotated source, some
	  function level information, and compiler commentary
	  messages. (See the analyzer(1) man page.)

	  The commentary messages generated with -g describe the
	  optimizations	and transformations the	compiler made
	  while	compiling your program.	 You must use er_src(1),
	  er_print(1), or the performance analyzer, analyzer(1)
	  to view the commentary messages.

	  Note that commentary messages	only appear if the
	  compiler actually performed any optimizations.  You are
	  more likely to see commentary	messages when you request
	  high optimization levels, such as with -xO4, or -fast.



     -h	nm
	  Specify the name of the generated dynamic shared
	  library

	  If the library has an	internal name, then whenever the
	  executable is	run, the linker	must find a library with
	  the same internal name; the file can be in any library
	  search path.	If the library has no internal name, then
	  the linker must find a library with the same path as
	  when it was generated.  Having an internal name allows
	  more flexibility at runtime.

	  Remarks:
	  o The	space between the -h and nm is optional.
	  o -hnm is meaningless	without	-G.
	  o -hnm is a linker option.
	  o The	names after -h and -o are usually the same.
	  o -hnm facilitates versions for dynamic libraries.

	  See the Solaris OS Linker and	Libraries Guide.

     -help
	  List the f95 command-line options.

	  See also -xhelp.

     -Ipath
	  Add path to the include file search path.

	  Insert directory path	path at	the start of the include
	  file search path. No space is	allowed	between	-I and
	  path.

	  The include file search path is the list of directories
	  searched for include files. This search path is used
	  by:

	    o	The preprocessor directive #include
	    o	The f95	statement INCLUDE

	  Example: To search for include files in /usr/applib:

	      f95 -I/usr/applib	growth.F

	  To invoke the	preprocessor, you must be compiling
	  source files with .F .F90 .F95 .F03 suffixes.

	  The search path is also used to search for MODULE
	  files.

	  The -Ipath search path is used while searching relative
	  path names on	INCLUDE	statements, not	absolute path
	  names. The search order for relative path names is:

	   1. The directory containing the source file
	   2. Directory	paths named in -I options
	   3. Directories in the default list of the compiler
	   4.  /usr/include


     -i8  (There is no -i8 option.)

	  Use -xtypemap=integer:64 to specify 8-byte INTEGER with
	  this compiler.


     -inline={%auto|[no%]function|...}
	  Enable/disable inlining of specified user-written
	  routines.

	  Optimize by inlining the specified user-written
	  routines named in the	comma-separated	list of	functions
	  and subroutines.

	  The argument list can	include	the string %auto to
	  enable automatic inlining at optimization levels -O4 or
	  higher. Automatic inlining is	normally turned	off when
	  explicit inlining is specified on the	command	line by
	  -inline.

	  If you prefix	the name of a routine on the list with
	  no%, inlining	of that	routine	is inhibited.

	  For example, to enable automatic inlining while
	  disabling inlining of	a specific routine (gflub), use:

	     -O5 -inline=%auto,no%gflub

	  An empty list	turns off automatic inlining

	     -fast -inline=  sourcefile.f95

	  Here,	-fast implies -O5, which enables automatic
	  inlining. However, the -inline= with an empty	list
	  disables it.

	  Only routines	in the file being compiled are
	  considered. The optimizer decides which of these
	  routines are appropriate for inlining.

	  A routine is not inlined if any of the following
	  conditions apply, with no warnings:

	  o Optimization is less than -O3

	  o The	routine	cannot be found.

	  o Inlining it	is not profitable or safe.

	  o The	source is not in the file being	compiled unless
	    -xipo is also specified.

     -iorounding[={compatible |	processor-defined}]
	  Set rounding mode for	formatted input/output.

	  Sets the ROUND= specifier globally for all formatted
	  input/output.

	  With -iorounding=compatible, the value resulting from
	  data conversion is the closer	of the two nearest
	  representations, or the value	away from zero if the
	  value	is halfway between them.

	  With -iorounding=processor-defined, the rounding mode
	  is the processor's default mode. This	is the default
	  when -iorounding is not specified.

	  Specifying -iorounding without an argument is
	  equivalent to	-iorounding=compatible.

     -keeptmp
	  Retains the temporary	files that are created during
	  compilation.

     -Kpic
	  Synonym for -pic

     -KPIC
	  Synonym for -PIC

     -Lpath
	  Add path to list of directory	paths to search	for
	  libraries.

	  path is added	to the start of	the search list. A space
	  between -L and path is optional.

	  Note:	 Do not	use the	-Lpath option to specify /usr/lib
	  or /usr/ccs/lib, since they are searched by default,
	  and including	them here prevents using the unbundled
	  libm.

     -lx  Add library libx.a to	the linker's list of search
	  libraries.

	  Direct the loader to link with object	library	libx.a,
	  where	x is a string. See ld(1).

	  Example:  -lsumex links in the library libsumex.a

	  Order	on the Command Line:  Place -lx	options	after any
	  .f, .F, or .o	files. If you call functions in	libx, and
	  they reference functions in liby, then place -lx before
	  -ly.

	  Search Order for -lx files: The linker searches for
	  libraries in several locations. For details, see the
	  chapter, "Libraries,"	in the Fortran Programming Guide.
	  See also ld(1).

     -libmil
	  Inline selected libm math library routines for
	  optimization.

	  Some of the simpler library routines can be inlined by
	  the compiler.	This option inlines library calls
	  depending on the floating-point options and platform
	  currently being used.

     -loopinfo
	  Show which loops are parallelized

	  Show which loops are parallelized and	which are not.
	  This option is normally for use with the
	  -autopar option. It generates	a list of messages on
	  standard error.

     -Mpath
	  Specify MODULE directory, archive, or	file.

	  Look in path for Fortran 95 modules referenced in the
	  current compilation. This path is searched in	addition
	  to the current directory.

	  path can specify a directory,	.a archive file	of
	  precompiled module files, or a .mod precompiled module
	  file.	 The compiler determines the type of the file by
	  examining its	contents.

	  A .a archive file must be explicitly specified on a -M
	  option flag to be searched for modules. The compiler
	  will not search archive files	by default.

	  Only .mod files with the same	names as the MODULE names
	  appearing on USE statements will be searched.	For
	  example, the statement USE ME	causes the compiler to
	  look only for	the module file	me.mod

	  When searching for modules, the compiler gives higher
	  priority to the directory where the module files are
	  being	written. This is controlled by the -moddir flag
	  or the MODDIR	environment variable.  When neither are
	  specified, the default write-directory is the	current
	  directory. When both are specified, the write-directory
	  is the path specified	by the -moddir flag.

	  This means that if only the -M flag appears, the
	  current directory will be searched for modules first
	  before any object listed on the -M flag. To emulate the
	  behavior of previous releases, use:

	     -moddir=empty-dir -Mdir -M

	  where	empty-dir is the path to an empty directory.

	  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 Solaris, if the path identifies a regular file that
	  is not an archive or a module	file, the compiler passes
	  the option to	the linker, ld,	which will treat it as a
	  linker mapfile.  This	feature	is provided as a
	  convenience similar to the C and C++ compilers.

     -moddir=path
	  Specify the path to a	directory where	the compiler will
	  write	.mod MODULE files. The path can	also be	specified
	  by using the MODDIR environment variable. If both are
	  specified, this option flag takes precedence.

	  The default directory	for writing .mod files is the
	  current directory.


     -mt[={yes|no}]
	  Use this option to compile and link multithreaded code
	  using	the Solaris threads or POSIX threads API.  The
	  -mt=yes option assures that libraries	are linked in the
	  appropriate order.

	  This option passes -D_REENTRANT to the preprocessor.

	  header file and compile with the

	  On Linux platforms, only the POSIX threads API is
	  available.  (There is	no libthread on	Linux platforms.)
	  Consequently,	-mt=yes	on Linux platforms adds	-lpthread
	  instead of -lthread.	To use POSIX threads on	Linux
	  platforms, compile with -mt.

	  Note that when compiling with	-G,neither -ltread nor
	  -lpthread are	automatically included by -mt=yes.  You
	  will need to explicitly list these libraries when
	  building a shared library.

	  The -xopenmp option (for using the OpenMP shared-memory
	  parallelization API) includes	-mt=yes	automatically.

	  If you compile with -mt=yes and link in a separate
	  step,	you must use the -mt=yes option	in the link step
	  as well as the compile step.	If you compile and link
	  one translation unit with -mt=yes, you must compile and
	  link all units of the	program	with -mt=yes

	  -mt=yes is the default behavior of the compiler.  If
	  this behavior	is not desired use the option -mt=no.

	  The option -mt is equivalent to -mt=yes.

	  See also: -xnolib

     -m32 | -m64
	  Specify memory model for compiled binary object.

	  Use -m32 to create 32-bit executables	and shared
	  libraries. Use -m64 to create	64-bit executables and
	  shared libraries.

	  The ILP32 memory model (32-bit int, long, pointer data
	  types) is the	default	on all Solaris platforms and on
	  Linux	platforms that are not 64-bit enabled. The LP64
	  memory model (64-bit long, pointer data types) is the
	  default on Linux platforms that are 64-bit enabled.
	  -m64 is permitted only on platforms that are enabled
	  for the LP64 model.

	  Object files or libraries compiled with -m32 cannot be
	  linked with object files or libraries	compiled with
	  -m64.

	  When compiling applications with large amounts of
	  static data using -m64, -xmodel=medium may also be
	  required.

	  Be aware that	some Linux platforms do	not support the
	  medium model.

	  Note that in previous	compiler releases, the memory
	  model, ILP32 or LP64,	was implied by the choice of the
	  instruction set with -xarch. Starting	with the Sun
	  Studio 12 compilers, this is no longer the case. On
	  most platforms, just adding -m64 to the command line is
	  sufficient to	create 64-bit objects.

	  On Solaris, -m32 is the default. On Linux systems
	  supporting 64-bit programs, -m64 -xarch=sse2 is the
	  default.

	  See also -xarch.

     -native
	  Optimize for the host	system.

	  The -native option is	a synonym for the -xtarget=native
	  option.

     -noautopar
	  Cancel -autopar on the command line.

	  Cancel automatic parallelization of loops invoked by
	  -autopar on the command line.

     -nodepend
	  Cancel -depend in command line

	  Cancel dependence analysis invoked by	a -depend option
	  appearing earlier in the command line.

     -nofstore
	  (x86)	Cancel -fstore on command line

	  Cancels forcing expressions to have the precision of
	  the destination variable invoked by -fstore.

	  -nofstore is invoked by -fast. -fstore is the	usual
	  default.

     -nolib

	  Do not link with system libraries.

	  Do not automatically link with any system or language
	  library; that	is, do not pass	any default -lx	options
	  to ld.  The default is to link such libraries	into
	  executables automatically, without users specifying
	  them on the command line.

	  The system and language libraries are	required for
	  final	execution. It is your responsibility to	link them
	  in manually. This option provides you	complete control
	  (and responsibility).

	  The -nolib option makes it easier to link these
	  libraries statically.

     -nolibmil
	  Cancel -libmil on command line

	  Use with -fast to disable inlining of	libm math
	  routines:

	     demo% f95 -fast -nolibmil	...

     -noreduction
	  Cancel -reduction on command line

	  -reduction is	used along with	parallelization	options.
	  This option cancels a	-reduction appearing earlier on
	  the command line.

     -norunpath
	  Do not build a runtime library search	path into the
	  executable

	  If an	executable file	uses shared libraries, then the
	  compiler normally builds in a	path that tells	the
	  runtime linker where to find those shared libraries.
	  The path depends on the directory where you installed
	  the compiler.	The -norunpath option prevents that path
	  from being built into	the executable.

	  This option is helpful when libraries	have been
	  installed in some nonstandard	location, and you do not
	  wish to make the loader search down those paths when
	  the executable is run	at another site.  Compare with
	  -R.





     -O[n]
	  Specify optimization level (n).

	  If -O[n] is not specified, only a very basic level of
	  optimization limited to local	common subexpression
	  elimination and dead code analysis is	performed.  A
	  program's performance	can be significantly improved
	  when compiled	with an	explicit optimization level.

	  Each -On level includes the optimizations performed at
	  the levels below it. Generally, the higher the level of
	  optimization,	the better the runtime performance.
	  However, higher optimization levels can result in
	  increased compilation	time and larger	executable files.

	  There	are five optimization levels that you can specify
	  with -On.  The actual	optimizations performed	by the
	  compiler at each level could change with each	compiler
	  release.

	  Use of -O (which implies -O3)	or -fast (which	implies
	  -O5) is recommended for most programs.

	  The -g option	can be used with optimization.

	  If the optimizer runs	out of memory, it attempts to
	  proceed over again at	a lower	level of optimization,
	  resuming compilation of subsequent routines at the
	  original level.

	  For details on optimization, see the Fortran
	  Programming Guide chapters Performance Profiling, and
	  Performance and Optimization.


	  -O   Optimize	at the level most likely to give close to
	       the maximum performance for many	realistic
	       applications (equivalent	to -O3).

	  -O1  Do only the basic local optimizations (peephole).

	  -O2  Do basic	local and global optimization. This level
	       usually gives minimum code size.

	  -O3  Adds global optimizations at the	function level.
	       In general, this	level, and -O4,	usually	result in
	       the minimum code	size when used with the	-xspace
	       option.	Automatically turns on -depend data
	       dependence analysis.

	  -O4  Adds automatic inlining of functions in the same
	       file. -O4 results in larger code	unless combined
	       with -xspace.

	       See -inline to control which routines are inlined.

	  -O5  Does the	highest	level of optimization, suitable
	       only for	the small fraction of a	program	that uses
	       the largest fraction of computer	time. Uses
	       optimization algorithms that take more compilation
	       time or that do not have	as high	a certainty of
	       improving execution time.  Optimization at this
	       level is	more likely to improve performance if it
	       is done with profile feedback. See
	       -xprofile=collect|use.

	  Interactions:

	       If you use -g and the optimization level	is -O3 or
	       lower, the compiler provides best-effort	symbolic
	       information with	almost full optimization. Tail-
	       call optimization and back-end inlining are
	       disabled.

	       For more	information, see Debugging a Program With
	       dbx.

	       See also:  -fast, -xprofile=p, csh(1) man page


     -o	nm
	  Specify the name of the executable file to be	written

	  There	must be	a blank	between	-o and nm. Without this
	  option, the default is to write the executable to
	  a.out.  When used with -c, -o	specifies the target .o
	  object file; with -G it specifies the	target .so
	  library file.

     -onetrip
	  Enable one-trip DO loops.

	  Compile DO loops so they are performed at least once if
	  reached.

	  Fortran 95 DO	loops are not performed	at all if the
	  upper	limit is smaller than the lower	limit, unlike
	  some legacy implementations of Fortran.

     -openmp
	  Synonym for -xopenmp

     -p	  (Obsolete) Compile for profiling with	prof.

	  Prepare object files for profiling with prof(1).  This
	  option makes profiles	by procedure, showing the number
	  of calls to each procedure and the percent of	time used
	  by each procedure.

	  For separate compile and link	steps, and if you compile
	  with -p, then	be sure	to link	with -p.

	  This option is now obsolete. Use -g and the performance
	  analyzer analyzer(1) instead.

     -pad[=p]
	  Insert padding for efficient use of cache.

	  This option inserts padding between arrays or	character
	  strings if they are:
	    o	Static local and not initialized, or
	    o	In common blocks

	  For either one, the arrays or	character strings can not
	  be equivalenced.

	  If =p	is present, it must be one of the following (no
	  spaces):
	    %none:  No padding is done.
	    local:  Pad	local variables
	    common:  Pad variables in common blocks
	    local,common:  Both	local and common padding is done.
	    local and common can appear	in any order.

	  Defaults:
	    The	compiler default is to do no padding.
	    Specifying -pad, without a value is	equivalent to
	    -pad=local,common

	    The	program	must conform to	the following
	    restrictions:

	  o    If -pad=common is specified for a file that
	       references a common block, it must be specified
	       for all files that reference that common	block.

	  o    With -pad=common	specified, the layout of
	       variables in the	same common block in different
	       program units must be the same except for the
	       names of	the variables.

	  o    Padding is dependent on the setting of -xcache.
	       All files must be compiled with the same	-xcache
	       settings	when -pad=common is used.

	  o    Do not specify -pad=common if the program
	       overindexes arrays in common blocks. The	padding
	       inserted	between	arrays by the compiler will
	       interfere with the assumed layout of the	data, and
	       will cause the array references to fail in
	       unpredictable ways.

	  o    EQUIVALENCE declarations	involving common block
	       variables will cause warning messages that padding
	       has been	inhibited by EQUIVALENCE when compiled
	       with -pad=common.  These	arrays will not	be
	       padded.

	  It is	the programmer's responsibility	to make	sure that
	  common blocks	are compiled consistently when -pad is
	  used.	 Common	blocks appearing in different program
	  units	that are compiled inconsistently with -pad=common
	  will cause errors. Compiling with -Xlist will	report
	  when common blocks with the same name	have different
	  lengths in different program units.


     -pg  Prepares the object code to collect data for profiling
	  with gprof(1).

	  Invokes a runtime recording mechanism	that produces a
	  gmon.out file	(at normal termination).

	  Note:	There is no advantage compiling	with -xprofile if
	  you specify -xpg. The	two do not prepare or use data
	  provided by the other.

	  Profiles are generated by using prof or gprof	on 64 bit
	  Solaris platforms or just gprof on 32	bit Solaris
	  platforms include approximate	user CPU times.	These
	  times	are derived from PC sample data	(see pcsample(2))
	  for routines in the main executable and routines in
	  shared libraries specified as	linker arguments when the
	  executable is	linked.	 Other shared libraries
	  (libraries opened after process startup using
	  dlopen(3DL)) are not profiled.

	  On 32	bit Solaris systems, profiles generated	using
	  prof(1) are limited to routines in the executable. 32
	  bit shared libraries can be profiled by linking the
	  executable with -xpg and using gprof(1).

	  The Solaris 10 software does not include system
	  libraries compiled with -p. As a result, profiles
	  collected on Solaris 10 platforms do not include call
	  counts for system library routines.

	  NOTE:	The compiler options -p, -pg, or -xpg should not
	  be used to compile multi-threaded programs, because the
	  runtime support for these options is not thread-safe.
	  If a program that uses multiple threads is compiled
	  with these options invalid results or	a segmentation
	  fault	could occur at runtime.

	  For separate compile and link	steps, if you compile
	  with -pg, then link with -pg.

     -pic Compile position-independent code for	shared library.

	  On SPARC, this is equivalent to -xcode=pic13

	  On x86, produces position-independent	code. Use this
	  option to compile source files when building a shared
	  library. Each	reference to a global datum is generated
	  as a dereference of a	pointer	in the global offset
	  table. Each function call is generated in pc-relative
	  addressing mode through a procedure linkage table.

     -PIC On SPARC, this is equivalent to -xcode=pic32

	  On x86, -PIC is identical to -pic

     -Qoption pr ls
	  Pass option list ls to the compilation phase pr.

	  This option is used primarily	by customer service.


     -qp  Synonym for -p.

     -R	list
	  Build	library	search paths into executable

	  With this option, the	linker,	ld(1), adds a list of
	  library search paths into the	executable file.

	  list is a colon-separated list of directories	used to
	  specify library search paths to the runtime linker. The
	  list is added	to the default list that f95 passes to
	  the linker.

	  The blank between -R and list	is optional.

	  Multiple instances of	this option are	concatenated
	  together, with each list separated by	a colon.

	  Use this option if you want to export	an executable
	  that can run without any special option for paths to
	  your dynamic libraries.

	  Building an executable with this option adds paths to	a
	  default path that is always searched last:
	     <installpath</f3/lib

	  The default library search order can be seen by using
	  the -dryrun option and examining the -Y option of the
	  ld invocation.

     -r8const
	  Promote single-precision constants to	REAL*8 constants.

	  All single precision literal constants are promoted to
	  REAL*8. Double-precision constants (REAL*8) are not
	  promoted.

	  This flag applies only to constants. Use -xtypemap to
	  promote both constants and variables.

	  Use this flag	carefully. It could cause interface
	  problems when	calling	a routine with a REAL*4	literal
	  constant as an actual	argument where a REAL*4	value is
	  expected. It could also cause	problems with programs
	  reading unformatted data files written by a write
	  statement with a literal REAL*4 constant on its I/O
	  list.

     -recl=a[,b]
	  Set default output record length.

	  Set the default record length	(in characters)	for
	  either or both preconnected units output (standard
	  output) and error (standard error).

	  This option must be specified	using one of the
	  following forms:

	  -recl=out:N
	  -recl=error:N
	  -recl=out:N1,error:N2
	  -recl=error:N1,out:N2
	  -recl=all:N

	  where	N, N1, N2 are all positive integers in the range
	  from 72 to 2147483646.

	  out refers to	standard output, error to standard error,
	  and all sets the default record length to both.

	  The default -recl=all:80.

	  This option is only effective	if the program being
	  compiled has a Fortran main program.
     -reduction
	  Parallelize reduction	operations in loops

	  Analyze loops	for reduction in automatic
	  parallelization. To enable parallelization of	reduction
	  loops, specify both -reduction and -autopar.

	  Example:  demo% f95 -autopar -reduction any.f

	  A loop that transforms the elements of an array into a
	  single scalar	value is called	a reduction operation.
	  For example, summing the elements of a vector	is a
	  typical reduction operation. Although	these operations
	  violate the criteria for parallelization, the	compiler
	  can recognize	them and parallelize them as special
	  cases	when -reduction	is specified. See the Fortran
	  Programming Guide chapter Parallelization for
	  information on reduction operations recognized by f95.
	  If you specify -reduction without -autopar, the
	  compiler issues a warning.

	  On a single-processor	system,	the generated code
	  usually runs more slowly.

	  There	is always potential for	roundoff error with
	  reduction.

     -S	  Compile and only generate assembly code.

	  Compile the named programs and leave the assembly
	  language output on corresponding files suffixed .s (no
	  .o file is created).

     -s	  Strip	the symbol table from the executable file.

	  This option makes the	executable file	smaller	and more
	  difficult to reverse engineer. However, this option
	  prevents debugging.

     -sb  (Obsolete) Produce table information for the source
	  browser.

	  The source browser is	no longer supported. This option
	  is ignored.

     -sbfast
	  (Obsolete) Similar to	-sb, but faster.

	  The source browser is	no longer supported. This option
	  is ignored.

     -silent

	  Suppress compiler messages.

	  Normally, f95	does not issue messages, other than error
	  diagnostics, during compilation. This	option is
	  provided only	for compatibility with older scripts and
	  makefiles. -silent is	the default and	its use	is
	  redundant.


     -stackvar
	  Force	all local variables to be allocated on the stack.

	  Allocates all	the local variables and	arrays in
	  routines onto	the memory stack unless	otherwise
	  specified. This option makes these variables automatic
	  rather than static and provides more freedom to the
	  optimizer when parallelizing loops with calls	to
	  subprograms.

	  Use of -stackvar is required with explicitly
	  parallelized loops containing	subprogram calls,  and
	  recommended for any of the parallelization options.
	  -stackvar is automatically included when -xopenmp is
	  used.	 See the Parallelization chapter in the	Fortran
	  Programming Guide for	additional information on when -
	  stackvar should and should not be used.

	  Variables and	arrays are local, unless they are:

	  o    Arguments in a SUBROUTINE or FUNCTION statement
	       (already	on stack)

	  o    Global items in a COMMON	or SAVE, or STATIC
	       statement

	  o    Initialized items in a type statement or	a DATA
	       statement, such as:
		   REAL	X/8.0/ or DATA X/8.0/

	  Putting large	arrays onto the	stack with -stackvar can
	  overflow the stack causing segmentation faults.
	  Increasing the stack size might be required.

	  The initial thread executing the program has a main
	  stack, while each helper thread of a multithreaded
	  program has its own thread stack.

	  The default size for the main	stack is about 8
	  Megabytes.  The default helper thread	stack size is 4
	  Megabytes on 32-bit platforms	and 8 Megabytes	on 64-bit
	  platforms.

	  The limit command (with no parameters) shows the
	  current main stack size.

	  Use the limit	shell command to set the size (in
	  Kilobytes) of	the main thread	stack.	For example, to
	  set the main stack size to 64	Megabytes, use a
	     % limit stacksize 65536
	  command.

	  You can set the stack	size to	be used	by each	slave
	  thread by giving the STACKSIZE environment variable a
	  value	(in Kilobytes):
	     % setenv STACKSIZE	8192
	  sets the stack size for each slave thread to 8 Mb.

	  The STACKSIZE	environment variable also accepts
	  numerical values with	a suffix of either B, K, M, or G
	  for bytes, kilobytes,	megabytes, or gigabytes
	  respectively.	 The default is	kilobytes.

	  See the Fortran Programming Guide chapter on
	  parallelization for details.

	  See also -xcheck=stkovf to enable runtime checking for
	  stack	overflow situations.

     -stop_status[={yes|no}]
	  Permit STOP statement	to return an integer status
	  value.

	  The optional argument	is either yes or no.  The default
	  is yes.

	  With -stop_status=yes	a STOP statement can contain an
	  integer constant that	will be	passed to the environment
	  as the program terminates.  This value will be
	  available as $status for the C shell or $? for the
	  Bourne and Korn shells.

	  The value on the STOP	statement can be any positive
	  integer.  The	value returned to the shell will be
	  modulo 256 (in the range 0 to	255).

     -temp=dir
	  Define directory for temporary files.

	  Set the directory for	temporary files	used by	f95 to be
	  dir instead of the /tmp directory.  This option has
	  precedence over the TMPDIR environment variable.

     -time
	  Show execution time for each compilation phase.
     -traceback[={%none|common|signals_list}]
	  Issue	a stack	trace if a severe error	occurs in
	  execution.

	  The -traceback option	causes the executable to issue a
	  stack	trace to stderr, dump core, and	exit if	certain
	  signals are generated	by the program.	 If multiple
	  threads generate a signal, a stack trace will	only be
	  produced for the first one.

	  To use traceback, add	the -traceback option to the
	  compiler command line	when linking.  The option is also
	  accepted at compile-time but is ignored unless an
	  executable binary is generated. Using	-traceback with
	  -G to	create a shared	library	is an error.

	  %none	or none
	       disables	traceback

	  common
	       specifies that a	stack trace should be issued if
	       any of a	set of common signals is generated --
	       sigill, sigfpe, sigbus, sigsegv,	and sigabrt.

	  signals_list
	       specifies a comma-separated list	of names of
	       signals which should generate a stack trace, in
	       lower case.  The	following signals (those that
	       cause the generation of a core file) can	be
	       caught:

	       sigquit,	sigill,	sigtrap, sigabrt, sigemt, sigfpe,
	       sigbus, sigsegv,	sigsys,	sigxcpu, sigxfsz

	       Any of these can	be preceeded with no% to disable
	       catching	the signal.

	       For example: -traceback=sigsegv,sigfpe will
	       produce a stack trace and core dump if either
	       sigsegv or sigfpe is generated.

	  If the option	is not specified, the default is
	  -traceback=%none

	  -traceback without any = sign	implies	-traceback=common

	  Note:	If the core dump is not	wanted,	users may set the
	  coredumpsize limit to	zero using:

	       % limit coredumpsize 0

	  The -traceback option	has no effect on runtime
	  performance.

     -U	  Recognize upper and lower case in source files.

	  Do not treat uppercase letters as equivalent to
	  lowercase. The default is to treat uppercase as
	  lowercase except within character-string constants.

	  With this option, the	compiler treats	Delta, DELTA, and
	  delta	as different symbols.

	  Portability and mixing Fortran with other languages
	  might	require	use of -U.

	  Calls	to intrinsic functions are not affected	by this
	  option.

     -Uname
	  Undefine preprocessor	macro name

	  Removes any initial definition of the	preprocessor
	  macro	symbol name created by -Dname on the same command
	  line,	or implicitly placed there by the command-line
	  driver, regardless of	the order the options appear. It
	  has no affect	on any macro definitions in source files.
	  Multiple -Uname flags	may appear on the same line, and
	  there	must be	no space between -U and	name.

	  This option applies only to .F, .F90,	.F95, and .F03
	  source files that invoke the fpp or cpp preprocessors.

     -u	  Report on undeclared variables.

	  Equivalent to	specifying IMPLICIT NONE in each
	  compilation unit. This has the affect	of making the
	  default type of variables undeclared rather than using
	  standard Fortran implicit typing. This option	does not
	  override any existing	IMPLICIT statements or explicit
	  type statements.

     -unroll=n
	  Enable unrolling of DO loops n times where possible.

	  n is a positive integer.

	  n = 1, inhibits all loop unrolling

	  n > 1, this option suggests to the optimizer that it
	  unroll loops n times.

	  If any loops are actually unrolled, then the executable
	  file is larger.
     -use=list
	  Specify implicit MODULE usage, globally.
	  list is a comma-separated list of module names or
	  module file names. Compiling with -use=module_name in
	  effect adds a	USE module_name	to each	subprogram being
	  compiled. Similarly, compiling with
	  -use=module_file_name	effectively adds to each
	  subprogram being compiled a USE module_name for each of
	  the modules contained	in the module_file_name	file.

     -V	  Show name and	version	of each	compilation phase.

     -v	  Verbose mode - show compilation details

	  Like -V but also details the options,	macro flag
	  expansions, and environment variables	used by	the
	  driver.

     -vax=v
	  Specify choice of VAX	VMS Fortran extensions enabled.

	  v must be one	of the following suboptions or a comma-
	  delimited list of a selection	of these.

	  blank_zero:	interpret blanks in formatted input as
			zeros on internal files.

	  debug:	interpret lines	starting with the
			character 'D' to be regular Fortran
			statements rather than comments, as in
			VMS Fortran.

	  rsize:	interpret unformatted record size to be
			in words rather	than bytes.

	  struct_align:	layout components of a VAX structure in
			memory as in VMS Fortran, without
			padding.  This option flag replaces the
			f77 -xl	flag.  Note:  this can cause data
			misalignments ("bus error") and	should be
			used with -xmemalign to	avoid such
			errors.

	  %all:		enable all these VAX VMS features.
			(Default.)

	  %none:	disable	all these VAX VMS features.

	  Sub-options can be individually selected or turned off
	  (by preceding	with no%).

	  Example:
	      -vax=debug,rsize,no%blank_zero

	  The default is -vax=%none.  If -vax is specified
	  without any suboptions, it is	equivalent to -vax=%all.

     -vpara
	  Show parallelization warning messages

	  Issues warnings about	potential parallel programming
	  related problems that	may cause incorrect results with
	  with -xopenmp	and OpenMP API directives.

	  Warnings are issued when the compiler	detects	the
	  following situations:
	  o

	  o    Problematic use of OpenMP data sharing attributes
	       clauses,	such as	declaring a variable "shared"
	       whose accesses in an OpenMP parallel region may
	       cause data race,	or declaring a variable	"private"
	       whose value in a	parallel region	is used	after the
	       parallel	region.

	  No warnings appear if	all parallelization directives
	  are processed	without	issues.

	  Example,
	  f95 -xopenmp -vpara any.f

	  Note:	Solaris	Studio compilers support OpenMP	3.0 API
	  parallelization.  See	the OpenMP API User's Guide for
	  information on migrating to the OpenMP API.

     -w[{0|1|2|3|4}]
	  Show or suppress warning messages.

	  -w suppresses	warning	messages from the compiler.
	  -w0 shows just error messages.
	  -w1 shows errors and warnings. (This is the default.)
	  -w2 shows errors, warnings, and cautions.
	  -w3 shows errors, warnings, cautions,	and notes.
	  -w4 shows errors, warnings, cautions,	notes, and
	  comments.

	  If you specify two options, and the second one
	  overrides all	or part	of the first one, the compiler
	  issues a warning.

     -Xlist[z]
	  Produce listings and do global program checking.

	  Find potential programming bugs. Invokes an extra
	  compiler pass	to check for consistency in calls and
	  common across	the global program. Generates line-
	  numbered source code listing with cross references.

	  Diagnostic messages from -Xlist are warnings and do not
	  prevent compiling and	linking.

	  Be sure to correct all syntax	errors first; -Xlist
	  might	produce	unpredictable reports when run on a
	  source program with syntax errors.

	  Output is to a file with a name like the first file
	  name but with	a .lst extension.

	  Example: Errors, listing, and	xref to	file1.lst

	     demo% f95 -Xlist file1.f file2.f

	  Use the -Xlist options to check for interprocedural
	  problems, but	only after all other compiler errors and
	  warnings have	been resolved.

	  Summary of -Xlist Suboptions

	  -Xlist	 Default: listings, errors, xref
	  -Xlistc	 Call graphs and errors.
	  -XlistE	 Errors	only (no xref or listings)
	  -Xlisterr	 Suppress all -Xlist error messages
	  -Xlisterr[n]	 Suppress -Xlist error message n.
	  -Xlistf	 Errors, listing, and cross references,
			 but no	object files compiled.
	  -Xlisth	 Terminate if errors detected.
	  -XlistI	 Check include files also
	  -XlistL	 Listings only (no xref)
	  -Xlistl[n]	 Page length is	n lines
	  -XlistMP	 (SPARC) Check OpenMP directives.
	  -Xlisto  nm	 Output	to nm instead of to file.lst
	  -Xlists	 Suppress unreferenced names from cross-
			 reference table.
	  -Xlistvn	 Set checking level to n (1,2,3, or 4) -
			 default is 2
	  -Xlistw[nnn]	 Set output line width to n; default is
			 79
	  -Xlistwar	 Suppress all -Xlist warning messages
	  -Xlistwar[n]	 Suppress -Xlist warning message n.
	  -XlistX	 Cross-reference only (no listings)

	  See the Fortran Programming Guide for	details.


     -xaddr32[={yes|no}]
	  (x86/x64 only) The -xaddr32=yes compilation flag
	  restricts the	resulting executable or	shared object to
	  a 32-bit address space.

	  An executable	that is	compiled in this manner	results
	  in the creation of a process that is restricted to a
	  32-bit address space.

	  When -xaddr32=no is specified	a usual	64 bit binary is
	  produced.

	  If the -xaddr32 option is not	specified, -xaddr32=no is
	  assumed.

	  If only -xaddr32 is specified	-xaddr32=yes is	assumed.

	  This option is only applicable to -m64 compilations and
	  only on Solaris platforms supporting SF1_SUNW_ADDR32
	  software capability.

	  Since	Linux kernel does not support addres space
	  limitation this option is not	available on Linux.  The
	  -xaddr32 option is ignored on	Linux.

	  When linking,	if a single object file	was compiled with
	  -xaddr32=yes the whole output	file is	assumed	to be
	  compiled with	-xaddr32=yes.

	  A shared object that is restricted to	a 32-bit address
	  space	must be	loaded by a process that executes within
	  a restricted 32-bit mode address space.

	  For more information refer to	the SF1_SUNW_ADDR32
	  software capabilities	definition, described in the
	  Linker and Libraries Guide.

     -xalias[=type_list]
	  Specify degree of aliasing to	be assumed by the
	  compiler.

	  Nonstandard programming techniques can introduce
	  situations that interfere with the compiler's
	  optimization strategies. In particular, the use of
	  overindexing,	pointers, and passing global or	non-
	  unique variables as subprogram arguments, introduce
	  ambiguous aliasing situations	that prevent the compiler
	  from applying	certain	optimizations, and can introduce
	  ambiguities that could result	in unexpected results.

	  See the Fortran User's Guide for more	information about
	  aliasing.

	  Use the -xalias flag to inform the compiler about the
	  ways in which	the program deviates from the aliasing
	  requirements of the Fortran standard.

	  The flag may appear with or without a	list. The
	  keywords on the list are comma-separated, and	each
	  keyword indicates an aliasing	situation present in the
	  program. Each	keyword	may be prefixed	by no% to
	  indicate an aliasing type that is not	present.

	  The aliasing keywords	are:

	  dummy	    Dummy (formal) subprogram parameters can
		    alias each other and global	variables.

	  no%dummy  (Default). Usage of	dummy parameters follows
		    the	Fortran	standard and may not alias each
		    other or global variables.

	  craypointer
		    (Default). Cray pointers can point at any
		    global variable or a local variable	whose
		    address is taken by	the LOC() function.
		    Also, two Cray pointers might point	at the
		    same data.	This is	a safe assumption that
		    could inhibit some optimizations.

	  no%craypointer
		    Cray pointers point	only at	unique memory
		    addresses, such as obtained	from malloc().
		    Also, no two Cray pointers point at	the same
		    data. This assumption enables the compiler to
		    optimize Cray pointer references.

	  actual    The	compiler treats	actual subprogram
		    arguments as if they were global variables.
		    Passing an argument	to a subprogram	might
		    result in aliasing through Cray pointers.

	  no%actual (Default). Passing an argument does	not
		    result in further aliasing.

	  overindex (a)	A reference to an element of an	array in
		    a COMMON block could refer to any element in
		    a COMMON block or equivalence group.
		    (b)	Passing	any element of a COMMON	block or
		    equivalence	group as an actual argument to a
		    subprogram gives access to any element of
		    that COMMON	block or equivalence group to the
		    called subprogram.
		    (c)	Elements of a sequence derived type are
		    treated as if they were COMMON blocks.
		    (d)	Individual array bounds	may be violated,
		    but	except as noted	above, the referenced
		    array element is assumed to	stay within the
		    array.

		    Array syntax, WHERE, and FORALL statements
		    are	not considered for overindexing.

	  no%overindex
		    (Default). Array bounds are	not violated.
		    Array references do	not reference other
		    variables.

	  ftnpointer
		    Calls to external functions	might cause
		    Fortran POINTERS to	point at TARGET	variables
		    of any type, kind, or rank.

	  no%ftnpointer
		    (Default). Fortran pointers	follow the rules
		    of the standard.

	  The default, when -xalias is not specified on	the
	  compiler command line, corresponds to:

	  -xalias=no%dummy,craypointer,no%actual,no%overindex,\
		   no%ftnpointer

	  Specifying -xalias without a list gives the best
	  performance for most programs	that do	not violate
	  Fortran aliasing rules, and corresponds to:

	  -xalias=no%dummy,no%craypointer,no%actual,no%overindex,\
		   no%ftnpointer

	  To be	effective, -xalias should be used when compiling
	  with optimization levels -xO3	and higher.

	  See the chapter on Porting in	the Fortran Programming
	  Guide	for further details.

     -xannotate[={yes|no}]
	  (Solaris Only) Instructs the compiler	to create
	  binaries that	can later be transformed by binary
	  modification tools like binopt(1). Future binary
	  analysis, code coverage and memory error detection
	  tools	will also work with binaries built with	this
	  option.

	  Use the -xannotate=no	option to prevent the
	  modification of the binary file by these tools.

	  The -xannotate=yes option must be used with
	  optimization level -xO1 or higher to be effective, and
	  it is	only effective on systems with the new linker
	  support library interface - ld_open(). If the	compiler
	  is used on a system without this linker interface (for
	  example Solaris 9 and	early versions of Solaris 10), it
	  silently will	revert to -xannotate=no.

	  The default is -xannotate=yes, but if	either of the
	  above	conditions is not met, the default reverts to
	  -xannotate=no.

	  This options is not available	on Linux systems.

     -xarch=isa
	  Specifies the	target architecture instruction	set
	  (ISA).

	  This option limits the code generated	by the compiler
	  to the instructions of the specified instruction set
	  architecture by allowing only	the specified set of
	  instructions.	This option does not guarantee use of any
	  target-specific instructions.	 However, use of this
	  option can affect the	portability of a binary	program.
	  See the Notes	and Warnings sections at the end of this
	  entry.

	  Note:	Use the	-m64 or	-m32 option to specify the
	  intended memory model, LP64 (64-bits)	or ILP32 (32-
	  bits)	respectively.  The -xarch flag no longer
	  indicates the	memory model, except for compatibility
	  with previous	releases, as indicated below.

	  If you compile and link in separate steps, make sure
	  you specify the same value for -xarch	in both	steps.

	  Values for all platforms:


	  Value	    Meaning

	  generic   This option	uses the instruction set common
		    to most processors.


	  generic64 Compile for	good performance on most 64-bit
		    platforms. (Solaris	only)

		    This option	is equivalent to
			-m64 -xarch=generic
		    and	is provided for	compatibility with
		    earlier releases.  Use -m64	to specify 64-bit
		    compilation	instead	of -xarch=generic64

	  native    Compile for	good performance on this system

		    The	compiler chooses the appropriate setting
		    for	the current system processor it	is
		    running on.


	  native64  Compile for	good performance on this system
		    (Solaris only)

		    This option	is equivalent to
		    -m64 -xarch=native and is provided for
		    compatibility with earlier releases.

	  Values specific to SPARC platforms:

	  sparc	    Compile for	the SPARC-V9 ISA.

		    Compile for	the V9 ISA, but	without	the
		    Visual Instruction Set (VIS), and without
		    other implementation-specific ISA extensions.
		    This option	enables	the compiler to	generate
		    code for good performance on the V9	ISA.


	  sparcvis  Compile for	the SPARC-V9 ISA plus VIS.

		    Compile for	SPARC-V9 plus the Visual
		    Instruction	Set (VIS) version 1.0, and with
		    UltraSPARC extensions.  This option	enables
		    the	compiler to generate code for good
		    performance	on the UltraSPARC architecture.


	  sparcvis2 Compile for	the SPARC-V9 ISA with UltraSPARC
		    III	extensions.

		    Enables the	compiler to generate object code
		    for	the UltraSPARC architecture, plus the
		    Visual Instruction Set (VIS) version 2.0, and
		    with UltraSPARC III	extensions.


	  sparcvis3 Compile for	the SPARC-V9 ISA with UltraSPARC
		    III	and VIS	3 extensions.

		    Enables the	compiler to use	instructions from
		    the	SPARC-V9 instruction set, plus the
		    UltraSPARC extensions, including the Visual
		    Instruction	Set (VIS) version 1.0, the
		    UltraSPARC-III extensions, including the
		    Visual Instruction Set (VIS) version 2.0, the
		    fused multiply-add instructions, and the
		    Visual Instruction Set (VIS) version 3.0


	  sparcfmaf Compile for	the sparcfmaf version of the
		    SPARC-V9 ISA.

		    Enables the	compiler to use	instructions from
		    the	SPARC-V9 instruction set, plus the
		    UltraSPARC extensions, including the Visual
		    Instruction	Set (VIS) version 1.0, the
		    UltraSPARC-III extensions, including the
		    Visual Instruction Set (VIS) version 2.0, and
		    the	SPARC64	VI extensions for floating-point
		    multiply-add.

		    Note that you must use -xarch=sparcfmaf in
		    conjunction	with -fma=fused	and some
		    optimization level to get the compiler to
		    attempt to find opportunities to use the
		    multiply-add instructions automatically.


	  sparcima  Compile for	the sparcima version of	the
		    SPARC-V9 ISA.

		    Enables the	compiler to use	instructions from
		    the	SPARC-V9 instruction set, plus the
		    UltraSPARC extensions, including the Visual
		    Instruction	Set (VIS) version 1.0, the
		    UltraSPARC-III extensions, including the
		    Visual Instruction Set (VIS) version 2.0, the
		    SPARC64 VI extensions for floating-point
		    multiply-add, and the SPARC64 VII extensions
		    for	integer	multiply-add.


	  v9	    Is equivalent to -m64 -xarch=sparc
		    Legacy makefiles and scripts that use
		    -xarch=v9 to obtain	the 64-bit memory model
		    need only use -m64.


	  v9a	    Is equivalent  to -m64 -xarch=sparcvis and is
		    provided for compatibility with earlier
		    releases.


	  v9b	    Is equivalent  to -m64 -xarch=sparcvis2 and
		    is provided	for compatibility with earlier
		    releases.

	  Notes:


	  o Legacy 32-bit SPARC	instruction set	architectures V7
	    and	V8 imply -m32 and cannot be combined with -m64.

	  o Object binary files	(.o) compiled with sparc and
	    sparcvis can be linked and can execute together, but
	    only on a sparcvis compatible platform.

	  o Object binary files	(.o) compiled with sparc,
	    sparcvis, and sparcvis2 can	be linked and can execute
	    together, but only on a sparcvis2 compatible
	    platform.

	    For	any particular choice, the generated executable
	    could run much more	slowly on earlier architectures.
	    Also, although quad-precision floating-point
	    instructions are available in many of these
	    instruction	set architectures, the compiler	does not
	    use	these instructions in the code it generates.


	  Values specific to x86 platforms:

	  Value	    Meaning

	  pentium_pro
		    Limits the instruction set to the pentium_pro
		    architecture.

	  sse	    Adds the SSE instruction set to the
		    pentium_pro	instruction set.

	  sse2	    Supplements	the pentium_pro	and SSE
		    instruction	sets with the SSE2 instruction
		    set.

	  sse3	    Supplements	the pentium_pro, SSE, and SSE2
		    instruction	sets with the SSE3 instruction
		    set.

	  ssse3	    Supplements	the pentium_pro, SSE, SSE2, and
		    SSE3 instruction sets with the SSSE3
		    instruction	set.

	  sse4_1    Supplements	the pentium_pro, SSE, SSE2, SSE3,
		    and	SSSE3 instruction sets with the	SSE4.1
		    instruction	set.

	  sse4_2    Supplements	the pentium_pro, SSE, SSE2, SSE3,
		    SSSE3, and SSE4.1 instruction sets with the
		    SSE4.2 instruction set.

	  amdsse4a  Uses the AMD SSE4a Instruction set.

	  amd64	    Is equivalent  to -m64 -xarch=sse2	(Solaris
		    only)
		    Legacy makefiles and scripts that use
		    -xarch=amd64 to obtain the 64-bit memory
		    model need only use	-m64.

	  pentium_proa
		    Adds the AMD extensions (3DNow!, 3DNow!
		    extensions,	and MMX	extensions) to the
		    pentium_pro	architecture.

	  ssea	    Adds the AMD extensions (3DNow!, 3DNow!
		    extensions,	and MMX	extensions) to the 32-bit
		    SSE	architecture.

	  sse2a	    Adds the AMD extensions (3DNow!, 3DNow!
		    extensions,	and MMX	extensions) to the  SSE2
		    architecture.

	  amd64a    Is equivalent to -m64 -xarch=sse2a	(Solaris
		    only)

	  Note:	    If any part	of a program is	compiled or
		    linked on an x86 platform with -m64, then all
		    parts of the program must be compiled with
		    one	of these options as well.

		    For	details	on the various Intel instruction
		    set	architectures (SSE, SSE2, SSE3,	SSSE3,
		    and	so on) refer to	the Intel-64 and IA-32
		    Intel Architecture Software	Developer's
		    Manual
		    (http://developer.intel.com/products/processor/manuals/)

	  Defaults:
	    If -xarch=isa is not specified, the	defaults are:
		  -xarch=generic  on SPARC platforms
		  -xarch=generic   on x86/x64 platforms

	  Interactions:
	    Although this option can be	used alone, it is part of
	    the	expansion of the -xtarget option and can be used
	    to override	the -xarch value that is set by	a
	    specific -xtarget option.

	    For	example, -xtarget=ultra4 expands to
	    -xarch=sparcvis2 -xcache=64/32/4:8192/128/2
	    -xchip=ultra4

	  Warnings:
	    If this option is used with	optimization, the
	    appropriate	choice can provide good	performance of
	    the	executable on the specified architecture. An
	    inappropriate choice, however, might result	in
	    serious degradation	of performance or in in	a binary
	    program that is not	executable on all intended target
	    platforms.


     -xassume_control[=a[,a]...]
	  Set parameters to control ASSUME pragmas.

	  Use this flag	to control the way the compiler	handles
	  ASSUME pragmas in the	source code.

	  See the Fortran User's Guide for descriptions	of the
	  ASSUME pragmas.

	  The ASSUME pragmas provide a way for the programmer to
	  assert special information that the compiler can use
	  for better optimization. These assertions may	be
	  qualified with a probability value. Those with a
	  probability of 0 or 1	are marked as certain; otherwise
	  they are considered non-certain.

	  Assertions such as whether an	upcoming branch	will be
	  taken, the range of an integer value or expression, the
	  trip count of	an upcoming DO loop, among others, can be
	  made with an associated probability or certainty.

	  The suboptions recognized are:


	  optimize  The	assertions made	on ASSUME pragmas affect
		    optimization of the	program.

	  check	    The	compiler generates code	to check the
		    correctness	of all assertions marked as
		    certain, and emits a runtime message if the
		    assertion is violated; the program continues
		    if fatal is	not also specified.

	  fatal	    When used with check, the program will
		    terminate when an assertion	marked certain is
		    violated.

	  retrospective[:d]
		    The	d parameter is an optional tolerance
		    value, and must be a real positive constant
		    less than 1. The default is	".1".
		    retrospective compiles code	to count the
		    truth or falsity of	all assertions.	Those
		    outside the	tolerance value	d are listed on
		    output at program termination.

	  %none	    Ignores all	ASSUME pragmas.

	  If not specified on the compiler command-line, the
	  default is
	       -xassume_control=optimize
	  This means that the compiler recognizes ASSUME pragmas
	  and they will	affect optimization, but no checking is
	  done.

	  If specified without parameters, -xassume_control
	  implies
	      -xassume_control=check,fatal
	  In this case the compiler accepts and	checks all
	  certain ASSUME pragmas, but they do not affect
	  optimization.	Assertions that	are invalid cause the
	  program to terminate.



     -xautopar
	  Synonym for -autopar

     -xbinopt={prepare|off}
	  (SPARC) Instructs the	compiler to prepare the	binary
	  for later optimizations, transformations and analysis
	  with binopt(1). This option may be used for building
	  executables or shared	objects. This option must be used
	  with optimization level -xO1 or higher to be effective.
	  There	is a modest increase in	size of	the binary when
	  built	with this option on the	order of 5%.

	  If you compile in separate steps, -xbinopt must appear
	  on both compile and link steps:

	   example% f95	-o myprog -xbinopt=prepare a.o b.o c.f95

	  If some source code is not available for compilation,
	  this option may still	be used	to compile the remainder
	  of the code.	It should then be used in the link step
	  that creates the final binary. In such a situation,
	  only the code	compiled with this option can be
	  optimized, transformed or analyzed.

	  Compiling with -xbinopt=prepare and -g increases the
	  size of the executable by including debugging
	  information. The default is -xbinopt=off.


     -xcache=c
	  Define cache for optimizer

	  Define cache properties for use by optimizer.

	  c must be one	of the following:
	     o generic
	     o native
	     o s1/l1/a1[/t1]
	     o s1/l1/a1[/t1]:s2/l2/a2[/t2]
	     o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]

	  The si, li, ai, and ti, are defined as follows:

	  si The size of the data cache	at level i, in kilobytes

	  li The line size of the data cache at	level i, in bytes

	  ai The associativity of the data cache at level i

	  ti The number	of hardware threads sharing the	cache at
	     level i The ti parameters are optional. A value of	1
	     is	used if	not present.

	  This option specifies	the cache properties that the
	  optimizer can	use. It	does not guarantee that	any
	  particular cache property is used.

	  Although this	option can be used alone, it is	part of
	  the expansion	of the -xtarget	option;	its primary use
	  is to	override a value supplied by the -xtarget option.

	  The -xcache values are:

	  generic
		Define the cache properties for	good performance
		on most	platforms. This	is the default.

	  native
		Define the cache properties for	good performance
		on this	host platform.

	  s1/l1/a1[/t1]
		Define level 1 cache properties.

	  s1/l1/a1[/t1]:s2/l2/a2[/t2]
		Define levels 1	and 2 cache properties.

	  s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
		Define levels 1, 2, and	3 cache	properties.


     -xcg89
	  (SPARC) Synonym for -cg89.
	  This option is obsolete and should not be used.


     -xcg92
	  (SPARC) Synonym for -cg92.
	  This option is obsolete and should not be used.


     -xcheck=v
	  Perform special run-time checks.

	  v may	be chosen from:

	  %all %none stkovf no%stkovf init_local no%init_local

	  Note:	Only -xcheck=init_local	is accepted on x86
	  platforms.  %all turns on all	the special run-time
	  checks, while	%none turns them all off. The default
	  (when	-xcheck	is not specified on the	command	line) is
	  -xcheck=%none.

	  The suboptions may be	specified in a comma-delimited
	  list,	as in:
		 -xcheck=no%stkovf,init_local

	  -xcheck=stkovf
	      Detect stack overflow at runtime.	 Compiling with
	      -xcheck=stkovf generates code at each routine entry
	      to test for thread stack overflow.

	      -xcheck=no%stkovf	disables stack overflow	checking.

	      The default is to	do no runtime stack overflow
	      checking.

	      If a stack overflow is detected, a SIGSEGV fault
	      will be raised.

	      Note that	compiling with -xcheck=stkovf does not
	      guarantee	that all stack overflow	situations will
	      be detected since	they can occur in routines not
	      compiled with this option. Undetected stack
	      overflow can cause data corruption in a neighboring
	      thread's stack.


	  -xcheck=init_local
	      Perform special initialization of	local variables.

	      With this	option the compiler initializes	local
	      variables	to a value that	is likely to cause an
	      arithmetic exception if it is used before	it is
	      assigned by the program. Memory allocated	by the
	      ALLOCATE statement will also be initialized in this
	      manner.

	      Module variables,	STATIC and SAVE	local variables,
	      and variables in COMMON blocks are not initialized.
	      no%init_local disables this initialization and is
	      the default.

	      See the C	User's Guide description of this option
	      for a list of the	predefined values used by the
	      compiler to initialize variables.

     -xchip=c
	  Specify target processor for optimizer.

	  This option specifies	instruction timing properties by
	  specifying the target	processor.

	  Although this	option can be used alone, it is	part of
	  the expansion	of the -xtarget	option;	its primary use
	  is to	override a value supplied by the -xtarget option.

	  Some effects are:

	  o The	ordering of instructions, that is, scheduling

	  o The	way the	compiler uses branches

	  o The	instructions to	use in cases where semantically
	    equivalent alternatives are	available

	  Common -xchip	values on SPARC	are identified below.


	       sparc64vi
			Optimize for the SPARC64 VI processor.

	       sparc64vii
			Optimize for the SPARC64 VII processor.

	       ultra	Optimize for the UltraSPARC(TM)	chip.

	       ultra2	Optimize for the UltraSPARC II chip.

	       ultra2e	Optimize for the UltraSPARC IIe	chip.

	       ultra2i	Optimize for the UltraSPARC IIi	chip.

	       ultra3	Optimize for the UltraSPARC III	chip.
	       ultra3cu	Optimize for the UltraSPARC IIIcu chip.

	       ultra3i	Optimize for the UltraSPARC IIIi chip.

	       ultra4	Optimize for the UltraSPARC IV chip.

	       ultra4plus
			Optimize for the UltraSPARC IV+	chip.

	       ultraT1	Optimize for the UltraSPARC T1 chip.

	       ultraT2	Optimize for the UltraSPARC T2 chip.

	       ultraT2plus
			Optimize for the UltraSPARC T2+	chip.

	       ultraT3	Optimize for the UltraSPARC T3 chip.

	       generic	Optimize for good performance on most
			supported SPARC	platforms.  (This is the
			compiler default.)

	       native	Optimize for good performance on this
			host platform.

	  Less common SPARC processor names:

	       super
		    Optimize for the SuperSPARC	chip.

	       super2
		    Optimize for the SuperSPARC	II chip.

	       micro
		    Optimize for the MicroSPARC(TM) chip.

	       micro2
		    Optimize for the MicroSPARC	II chip.

	       hyper
		    Optimize for the HyperSPARC(TM) chip.

	       hyper2
		    Optimize for the HyperSPARC	II chip.


	  The -xchip values on x86 platforms are:

	       core2
		    Optimize for Intel Core2.

	       opteron

		    Optimize for AMD Opteron.

	       pentium
		    Optimize for Pentium.

	       pentium_pro
		    Optimize for Pentium Pro.

	       pentium3
		    Optimize for Pentium III.

	       pentium4
		    Optimize for Pentium 4.

	       generic
		    Optimize for most x86 platforms.

	       native
		    Optimize for this host processor.

	  For complete information, see	the Fortran User's Guide


     -xcode=v
	  (SPARC) Specify code address space

	  The following	values for -xcode are:


	  abs32	  Generate 32-bit absolute addresses.
		  Code + data +	bss size is limited to 2**32
		  bytes.  This is the default on 32-bit
		  architectures.


	  abs44	  Generate 44-bit absolute addresses.
		  Code + data +	bss size is limited to 2**44
		  bytes.  Available only on 64-bit architectures.


	  abs64	  Generate 64-bit absolute addresses.
		  Available only on 64-bit architectures.


	  pic13	  Generate position-independent	code (small
		  model).
		  Equivalent to	-pic.  Permits references to at
		  most 2**11 unique external symbols on	32-bit
		  architectures, 2**10 on 64-bit.


	  pic32	  Generate position-independent	code (large
		  model).
		  Equivalent to	-PIC.  Permits references to at
		  most 2**30 unique external symbols on	32-bit
		  architectures, 2**29 on 64-bit.

	  The default is -xcode=abs32 for 32-bit compilations,
	  and -xcode=abs44 for 64-bit compilations.

	  Position-Independent Code:

	     Use -xcode=pic13 or -xcode=pic32 when creating
	     dynamic shared libraries to improve runtime
	     performance.

	     While the code within a dynamic executable	is
	     usually tied to a fixed address in	memory,
	     position-independent code can be loaded anywhere in
	     the address space of the process.

	     When you use position-independent code, relocatable
	     references	are generated as an indirect reference
	     through a global offset table.  Frequently	accessed
	     items in a	shared object will benefit from	compiling
	     with -xcode=pic13 or -xcode=pic32 by not requiring
	     the large number of relocations imposed by	code that
	     is	not position-independent.

	     The size of the global offset table is limited to
	     8Kb on SPARC.

	     There are two nominal performance costs with
	     -xcode={pic13|pic32} :

	       o A routine compiled with either	-xcode=pic13 or
		 -xcode=pic32 executes a few extra instructions
		 upon entry to set a register to point at the
		 global	offset table used for accessing	a shared
		 library's global or static variables.

	       o Each access to	a global or static variable
		 involves an extra indirect memory reference
		 through the global offset table. If the compile
		 is done with pic32, there are two additional
		 instructions per global and static memory
		 reference.

	       When considering	the above costs, remember that
	       the use of -xcode=pic13 or -xcode=pic32 can
	       significantly reduce system memory requirements,
	       due to the effect of library code sharing. Every
	       page of code in a shared	library	compiled
	       -xcode=pic13 or -xcode=pic32 can	be shared by
	       every process that uses the library. If a page of
	       code in a shared	library	contains even a	single
	       non-pic (that is, absolute) memory reference, the
	       page becomes non-sharable, and a	copy of	the page
	       must be created each time a program using the
	       library is executed.

	       The easiest way to tell whether or not a	.o file
	       has been	compiled with -xcode=pic13 or
	       -xcode=pic32 is with the	nm command:

		   nm file.o | grep _GLOBAL_OFFSET_TABLE_

	       A .o file containing position-independent code
	       will contain an unresolved external reference to
	       _GLOBAL_OFFSET_TABLE_ as	marked by the letter U.

	       To determine whether to use -xcode=pic13	or
	       -xcode=pic32, check the size of the Global Offset
	       Table (GOT) by using elfdump -c (see the
	       elfdump(1) man page for more information) and for
	       the section header, sh_name: .got. The sh_size
	       value is	the size of the	GOT. If	the GOT	is less
	       than 8,192 bytes, specify -xcode=pic13, otherwise
	       specify -xcode=pic32.

	       In general, use the following guidelines	to
	       determine how you should	use -xcode:

	       o  If you are building an executable you	should
	       not use -xcode=pic13 or -xcode=pic32.

	       o  If you are building an archive library only for
	       linking into executables	you should not use
	       -xcode=pic13 or -xcode=pic32.

	       o  If you are building a	shared library,	start
	       with -xcode=pic13 and once the GOT size exceed
	       8,192 bytes, use	-xcode=pic32.

	       o  If you are building an archive library for
	       linking into shared libraries you should	just use
	       -xcode=pic32.

	       See the Solaris OS Linker and Libraries Guide.


     -xcommonchk[={yes|no}]
	  Enable runtime checking of common block
	  inconsistencies.

	  This option is provided as a debugging aid for programs
	  using	task common and	parallelization	(See the task
	  common pragma.)

	  Normally, runtime checking for inconsistent task common
	  declarations is disabled. Compiling with
	  -xcommonchk=yes enables runtime checking.

	  If a common block is declared	in one source module as	a
	  regular common block,	and somewhere else appears in a
	  task common pragma, the program will stop and	a message
	  pointing to the first	such inconsistency issued.

	  Because runtime checking degrades program performance,
	  it should only be used during	program	development and
	  debugging.

	  Specifying -xcommoncheck alone is equivalent to
	  -xcommoncheck=yes


     -xcrossfile[=n]
	  (Obsolete) Enable optimization and inlining across
	  source files

	  This option is now obsolete and should not be	used.

	  It now has the same effect as	-xipo.	Use -xipo
	  instead.


     -xdebugformat={stabs|dwarf}
	  The Solaris Studio compilers have migrated the format
	  of debugger information from the "stabs" format to the
	  "dwarf" format.  The default setting for this	release
	  is -xdebugformat=dwarf.

	  Use this option as a way of accessing	either format for
	  use by porting tools.	There is no need to use	this
	  option unless	you maintain software which reads
	  debugger information,	or unless a specific tool tells
	  you that it requires debugger	information in one of
	  these	formats.

	  -xdebugformat=stabs generates	debugging information
	  using	the stabs standard format.

	  -xdebugformat=dwarf generates	debugging information
	  using	the dwarf standard format.

	  If you do not	specify	-xdebugformat, the compiler
	  assumes -xdebugformat=dwarf. It is an	error to specify
	  the option without an	argument.
	  This option affects the format of the	data that is
	  recorded with	the -g option.	Some small amount of
	  debugging information	is recorded even without -g, and
	  the format of	that information is also controlled with
	  this option.	So -xdebugformat has a an effect even
	  when -g is not used.

	  The dbx and Performance Analyzer software understand
	  both stabs and dwarf format so using this option does
	  not have any effect on the functionality of either
	  tool.

	  This is a transitional interface which could change in
	  incompatible ways from release to release, even in a
	  minor	release.

	  The details of any specific fields or	values in either
	  stabs	or dwarf are also evolving.

	  Use the dwarfdump(1) command to determine whether an
	  object or executable file was	compiled with "dwarf" or
	  "stabs" debug	information.

     -xdepend
	  Synonym for -depend


     -xdryrun
	  Synonym for -dryrun



     -xF  Allow	function-level reordering by the 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
	  Solaris Studio. See the Performance Analyzer manual for
	  further information on the analyzer.


     -xfilebyteorder=options
	  Support file sharing between little-endian and big-
	  endian platforms.

	  The flag identifies the byte-order and byte-alignment
	  of unformatted I/O files.  options must specify any
	  combination of the following,	but at least one
	  specification	must be	present:

	  littlemax_align:spec
	  bigmax_align:spec
	  native:spec

	  max_align declares the maximum byte alignment	for the
	  target platform. Permitted values are	1, 2, 4, 8, and
	  16. The alignment applies to Fortran VAX structures and
	  Fortran 95 derived types that	use platform-dependent
	  alignments for compatibility with C language
	  structures.

	  little specifies a "little-endian" file on platforms
	  where	the maximum byte alignment is max_align. For
	  example, little4 specifies a 32-bit x86 file,	while
	  little16 describes a 64-bit x86 file.

	  big specifies	a "big-endian" file with a maximum
	  alignment of max_align.  For example,	big8 describes a
	  32-bit SPARC file, while big16 describes a 64-bit SPARC
	  file.

	  native specifies a "native" file with	the same byte
	  order	and alignment used by the compiling processor
	  platform. The	following are assumed to be "native":

		PLATFORM	 "NATIVE" IS
	      32-bit SPARC	   big8
	      64-bit SPARC	   big16
	      32-bit x86	   little4
	      64-bit x86	   little16

	  spec,	must be	a comma-separated list of the following:

	  %all
	  unit
	  filename

	  %all refers to all files and logical units except those
	  opened as "SCRATCH", or named	explicitly elsewhere in
	  the -xfilebyteorder flag. %all can only appear once.

	  unit refers to a specific Fortran unit number	opened by
	  the program.

	  filename refers to a specific	Fortran	file name opened
	  by the program.

	  Examples:
	   -xfilebyteorder=little4:1,2,afile.in,big8:9,bfile.out,12
	   -xfilebyteorder=little8:%all,big16:20

	  Notes:
	  This option does not apply to	files opened with
	  STATUS="SCRATCH". I/O	operations done	on these files
	  are always with the byte-order and byte-alignment of
	  the native processor.

	  The first default, when -xfilebyteorder does not appear
	  on the command line, is -xfilebyteorder=native:%all.

	  A file name or unit number can be declared only once in
	  this option.

	  When -xfilebyteorder does appear on the command line,
	  it must appear with at least one of the little, big, or
	  native specifications.

	  Files	not explicitly declared	by this	flag are assumed
	  to be	native files.  For example, compiling with
	  xfilebyteorder=little4:zork.out declares zork.out to be
	  a little-endian 32-bit x86 file with a 4-byte	maximum
	  data alignment. All other files in the program are
	  native files.

	  When the byte-order specified	for a file is the same as
	  the native processor but a different alignment is
	  specified, the appropriate padding will be used even
	  though no byte swapping is done. For example,	this
	  would	be the case when compiling with	-m64 for 64-bit
	  x86 platforms	and -xfilebyteorder=little4:filename is
	  specified.

	  The declared types in	data records shared between big-
	  endian and little-endian platforms must have the same
	  sizes. For example, a	file produced by a SPARC
	  executable compiled with
	  -xtypemap=integer:64,real:64,double:128 cannot be read
	  by an	x86 executable compiled	with
	  -xtypemap=integer:64,real:64,double:64 since the
	  default double precision data	types will have	different
	  sizes.

	  Note that with this release, Solaris Studio sotware now
	  supports REAL*16 data	on x86 platforms.  Unformatted
	  files	containing REAL*16 data	can now	be used	on X86
	  platforms.

	  An I/O operation with	an entire UNION/MAP data object
	  on a file specified as non-native will result	in a
	  runtime I/O error.  You can only execute I/O operations
	  using	the individual members of the MAP (and not an
	  entire VAX record containing the UNION/MAP) on non-
	  native files.

     -xhasc[={yes|no}]
	  Treat	Hollerith constant as character	string in actual
	  argument lists.

	  With -xhasc=yes the compilers	treat as character
	  strings Hollerith constants appearing	as an actual
	  argument in a	subprogram call.  This is the default and
	  complies with	the Fortran 77 standard.

	  With -xhasc=no Hollerith constants are treated as
	  typeless values in subprogram	call lists.

	  This flag is provided	to aid porting older Fortran
	  programs.  Compile routines calling subprograms with
	  Hollerith constants with -xhasc=no if	the called
	  subprogram expects that argument as INTEGER or any
	  other	type other than	CHARACTER.


     -xhelp=h
	  Show options summary or README file.

	  h is either readme or	flags.

	  readme:  Show	the online README file.
	  flags:  Show the compiler flags (options).

	  -xhelp=flags is a synonym for	-help.


     -xhwcprof[={enable|disable}]
	  (SPARC) Enable compiler support for dataspace
	  profiling.

	  When -xhwcprof is enabled, the compiler generates
	  information that helps tools associate profiled load
	  and store instructions with the data-types and
	  structure members (in	conjunction with symbolic
	  information produced with -g)	to which they refer.  It
	  associates profile data with the data	space of the
	  target, rather than the instruction space, and provides
	  insight into behavior	that is	not easily obtained from
	  only instruction profiling.

	  While	you can	compile	a specified set	of object files
	  with -xhwcprof, this option is most useful when applied
	  to all object	files in the application. This will
	  provide coverage to identify and correlate all memory
	  references distributed in the	application's object
	  files.

	  If you are compiling and linking in separate steps, use
	  -xhwcprof at link time as well.

	  An instance of -xhwcprof=enable or -xhwcprof=disable
	  overrides all	previous instances of -xhwcprof	in the
	  same command line.

	  -xhwcprof is disabled	by default. Specifying -xhwcprof
	  without any arguments	is the equivalent to
	  -xhwcprof=enable.

	  -xhwcprof requires that optimization be turned on and
	  that the debug data format be	set to dwarf
	  (-xdebugformat=dwarf), which is now the default with
	  this release of the Solaris Studio compilers.

	  The combination of -xhwcprof and -g increases	compiler
	  temporary file storage requirements by more than the
	  sum of the increases due to -xhwcprof	and -g specified
	  alone.

	  The following	command	compiles example.f and specifies
	  support for hardware counter profiling and symbolic
	  analysis of data types and structure members using
	  DWARF	symbols:

	  example% f95 -c -O -xhwcprof -g example.f

	  For more information on hardware counter-based
	  profiling, see the Performance Analyzer manual.


     -xia[={widestneed|strict}]
	  Enable interval arithmetic extensions	and set	a
	  suitable floating-point environment.

	  Interval arithmetic is an extension to the numerical
	  computation techniques in Fortran 95.	For further
	  information, see the Fortran 95 documentation.
	  -xia is a macro flag that expands as follows:


	  -xia and -xia=widestneed expand to:
	    -xinterval=widestneed -ftrap=%none -fns=no -fsimple=0


	  -xia=strict expands to:
	    -xinterval=strict -ftrap=%none -fns=no -fsimple=0

	    On x86 platforms, -xarch=sse2 must be specified for
	    32-bit compilations. -xia is not available on Linux
	    platforms.

	    For	more information, see the Fortran 95 Interval
	    Arithmetic Programming Reference.


     -xinline=rl
	  Synonym for -inline=rl.


     -xinstrument=[no%]datarace]

	  Specify this option to compile and instrument	your
	  program for analysis by the Thread Analyzer. For more
	  information on the Thread Analyzer, see tha(1) for
	  details.

	  You can then use the Performance Analyzer to run the
	  instrumented program with collect -r races to	create a
	  data-race-detection experiment. You can run the
	  instrumented code standalone but it runs more	slowly.

	  Specify -xinstrument=no%datarace to turn off this
	  feature.  This is the	default.

	  -xinstrument must be specified with an argument.

	  If you compile and link in seperate steps, you must
	  specify -xinstrument=datarace	in both	the compilation
	  and linking steps.

	  This option defines the preprocessor token
	  __THA_NOTIFY.	You can	specify	#ifdef __THA_NOTIFY to
	  guard	calls to libtha(3) routines.

	  This option also sets	-g.

     -xinterval[={widestneed|strict|no}]
	  (SPARC) Enable processing of interval	arithmetic
	  extensions.
	  Interval arithmetic is an extension to the numerical
	  computation techniques in Fortran 95.	For further
	  information, see the Fortran 95 documentation.

	  This flag controls the expression evaluation syntax
	  permitted.

	  -xinterval specified without a value defaults	to
	  widestneed.


	  no
	    Interval arithmetic	is not enabled.


	  widestneed
	    Promotes all non-interval variables	and literals in
	    any	mixed-mode expression to the widest interval data
	    type in the	expression.


	  strict
	    Prohibits mixed-type or mixed-length interval
	    expressions. All interval type and length conversions
	    must be explicit.



     -xipo[={1|0|2}]
	  Perform interprocedural optimizations.

	  Invoke interprocedural analysis pass to perform whole-
	  program optimizations. Unlike	-xcrossfile, -xipo
	  optimizes across all object files in the link	step, and
	  is not limited to just the source files on the compile
	  command.

	  Analysis and optimization is limited to object files
	  compiled with	-xipo.

	  -xipo=0 disables interprocedural analysis.
	  -xipo=1 enables inlining across source files.
	  -xipo=2 adds whole-program detection and analysis,
	  including memory allocation and memory layout
	  optimizations	to improve cache performance.

	  The default is -xipo=0

	  If specified without a value,	-xipo=1	is assumed.

	  When compiling with -xipo=2, there should be no calls
	  from functions or subroutines	compiled without -xipo=2
	  (for example,	from libraries)	to functions or
	  subroutines compiled with -xipo=2.  Otherwise, the
	  assumptions made by the compiler about the usage of
	  these	called routines	could be incorrect.

	  See the Fortran 95 User's Guide for additional
	  information about when not to	use -xipo.

	  When compiling and linking in	separate steps,	you must
	  specify -xipo	in both	steps to be effective.

	  Libraries, even if compiled with -xipo do not
	  participate in crossfile interprocedural analysis.
	  Also,	.s assembly language source files do not
	  participate in the analysis.

	  The -xipo flag is ignored if compiling with -S.

	  Additional information about -xipo:
	    Requires at	least optimization level -xO4

	    Do not use with -xcrossfile. If used together a
	    compilation	error will result.

	    Building executables compiled with -xipo using a
	    parallel make tool can cause problems if object files
	    used in the	build are common to the	link steps
	    running in parallel. Each link step	should have its
	    own	copy of	the object file	being optimized	prior to
	    linking.

	    Objects compiled without -xipo can be linked freely
	    with objects not compiled with this	flag.

	    See	also -xjobs.

     -xipo_archive={none|readonly|writeback}
	  (SPARC) Allow	crossfile optimization to include archive
	  (.a) libraries.

	  none	  There	is no processing of archive files.
		  The compiler does not	apply cross-module
		  inlining or other cross-module optimizations to
		  object files compiled	using -xipo and	extracted
		  from an archive library at link time.	 To do
		  that,	both -xipo and either
		  -xipo_archive=readonly or
		  -xipo_archive=writeback must be specified at
		  link time.

	  readonly
		  The compiler optimizes object	files passed to
		  the linker with object files compiled	with
		  -xipo	that reside in the archive library (.a)
		  before producing an executable.

		  The option -xipo_archive=readonly enables
		  cross-module inlining	and interprocedural data
		  flow analysis	of object files	in an archive
		  library specified at link time.  However, it
		  does not enable cross-module optimization of
		  the archive library's	code except for	code that
		  has been inserted into other modules by cross
		  module inlining.

		  To apply cross-module	optimization to	code
		  within an archive library,
		  -xipo_archive=writeback is required.	Note that
		  doing	so modifies the	contents of the	archive
		  library from which the code was extracted.

	  writeback
		  The compiler optimizes object	files passed to
		  the linker with object files compiled	with
		  -xipo	that reside in the archive library (.a)
		  before producing an executable. Any object
		  filed	contained in the library that were
		  optimized during the compilation are replaced
		  with their optimized version.

		  For parallel links that use a	common set of
		  archive libraries, each link should create its
		  own copy of archive libraries	to be optimized
		  before linking.

	  If you do not	specify	a setting for -xipo_archive, the
	  compiler assumes -xipo_archive=none.

     -xivdep[=p]
	  Disable or set interpretation	of IVDEP directives

	  The IVDEP directive tells a compiler to ignore some or
	  all loop-carried dependences on array	references that
	  it finds in a	loop for purposes of optimization.  This
	  enables a compiler to	perform	various	loop
	  optimizations	such as	microvectorization, distribution,
	  software pipelining, etc., which would not be	otherwise
	  possible.  It	is used	in cases where the user	knows
	  either that the dependences do not matter or that they
	  never	occur in practice.

	  The interpretation of	!DIR IVDEP directives depend upon
	  the value of the -xivdep option.

	  The following	values for p are interpreted as	follows:

	  loop - ignore	assumed	loop-carried vector dependences
	  loop_any - ignore all	loop-carried vector dependences
	  back - ignore	assumed	backward loop-carried vector
	  dependences
	  back_any - ignore all	backward loop-carried vector
	  dependences
	  none - do not	ignore any dependences (disables IVDEP
	  directives)

	  These	interpretations	are provided for compatibility
	  with other vendor's interpretations of the IVDEP
	  directive.

	  For details, see the Fortran User's Guide.



     -xjobs=n
	  Compile with multiple	processors.

	  Specify the -xjobs option to set how many processes the
	  compiler creates to complete its work. This option can
	  reduce the build time	on a multi-cpu machine.
	  Currently, -xjobs works only with the	-xipo option.
	  When you specify -xjobs=n, the interprocedural
	  optimizer uses n as the maximum number of code
	  generator instances it can invoke to compile different
	  files.

	  Generally, a safe value for n	is 1.5 multiplied by the
	  number of available processors. Using	a value	that is
	  many times the number	of available processors	can
	  degrade performance because of context switching
	  overheads among spawned jobs.	Also, using a very high
	  number can exhaust the limits	of system resources such
	  as swap space.

	  You must always specify -xjobs with a	value. Otherwise
	  an error diagnostic is issued	and compilation	aborts.

	  Multiple instances of	-xjobs on the command line
	  override each	other until the	rightmost instance is
	  reached.

	  The following	example	compiles more quickly on a system
	  with two processors than the same command without the
	  -xjobs option.

	  example% f95 -xipo -xO4 -xjobs=3 t1.f	t2.f t3.f

     -xkeepframe[=[%all,%none,function_name,no%function_name]]
	  Prohibit stack related optimizations for the named
	  functions.

	  %all - prohibit stack	related	optimizations for all the
	  code
	  %none	- allow	stack related optimizations for	all the
	  code

	  If not specified on the command line,	the compiler
	  assumes -xkeepframe=%none

	  If specified but without a value, the	compiler assumes
	  -xkeepframe=%all

     -xknown_lib=lib
	  Recognize calls to a known library.

	  With this flag specified, the	compiler treats
	  references to	certain	known libraries	as intrinsics,
	  ignoring any user-supplied versions. This enables the
	  compiler to perform optimizations over calls to library
	  routines based on special knowledge of that library.

	  lib may be any one of	the following key words, or a
	  comma-delimited list of a selection of them:


	     blas
	     blas1
	     blas2
	     blas3
	     intrinsics

	  -xknown_lib=[blas | blas1 | blas2 | blas3 ]
	     The compiler recognizes calls to the following BLAS
	     library routines and is free to optimize
	     appropriately for the Sun Performance Library
	     implementation.

	     BLAS1 routines recognized by -xknown_lib=blas1:

	     caxpy   ccopy   cdotc    cdotu   crotg
	     cscal   csrot   csscal   cswap   dasum
	     daxpy   dcopy   ddot     drot
	     drotg   drotm   drotmg   dscal   dsdot
	     dswap   dnrm2   dzasum   dznrm2  icamax
	     idamax  isamax  izamax   sasum   saxpy
	     scasum  scnrm2  scopy    sdot    sdsdot
	     snrm2   srot    srotg    srotm   srotmg
	     sscal   sswap   zaxpy    zcopy   zdotc
	     zdotu   zdrot   zdscal
	     zrotg   zscal   zswap

	     BLAS2 routines recognized by -xknown_lib=blas2:

	     cgemv   cgerc   cgeru   ctrmv   ctrsv
	     dgemv   dger    dsymv   dsyr    dsyr2
	     dtrmv   dtrsv   sgemv   sger
	     ssymv   ssyr    ssyr2   strmv   strsv
	     zgemv   zgerc   zgeru   ztrmv   ztrsv

	     BLAS3 routines recognized by -xknown_lib=blas3:

	     cgemm   csymm   csyr2k  csyrk   ctrmm
	     ctrsm   dgemm   dsymm   dsyr2k  dsyrk
	     dtrmm   dtrsm   sgemm   ssymm   ssyr2k
	     ssyrk   strmm   strsm   zgemm   zsymm
	     zsyr2k  zsyrk   ztrmm   ztrsm

	     You can select any	combination of these. For example
		-xknown_lib=blas2,blas3
	     selects just the BLAS2 and	BLAS3 routines.

	     You can select all	the BLAS routines by specifying
		-xknown_lib=blas
	     which is equivalent to
		-xknown_lib=blas1,blas2,blas3

	     The compiler will ignore user-supplied versions of
	     these library routines and	link to	the BLAS routines
	     in	the Sun	Performance Library.


	  -xknown_lib=intrinsics
	     Specifying	intrinsics has the effect of ignoring any
	     explicit EXTERNAL declarations for	Fortran	95
	     intrinsics, thereby ignoring any user-supplied
	     intrinsic routines.

	     For a list	of functions recognized	by the compiler
	     as	intrinsics, see	Chapters 2 and 3 of the	Fortran
	     Library Reference manual.


     -xl  (Obsolete)
	  This (f77) option is no longer supported.  For the
	  equivalent options in	the current Fortran compiler,
	  use:	-f77=%all,no%backslash -vax=$all,no%debug

     -xld (Obsolete)
	  This (f77) option is no longer supported.  For the
	  equivalent options in	the current Fortran compiler,
	  use:	-f77=%all,no%backslash -vax=$all,no%debug
     -xlang=f77
	  (SPARC) Include the appropriate runtime libraries and
	  insure the proper runtime environment	for legacy
	  Fortran 77.

	  Interactions:

	  The option -xlang=f77	implies	linking	with the
	  f77compat library, and is a shorthand	way for	linking
	  Fortran 95 object files with Fortran 77 object files.
	  Using	-xlang=f77 insures the proper runtime
	  environment.

	  Warnings:

	  Do not use -xnolib with -xlang.

	  If you are mixing Fortran object files with C++, link
	  with the C++ compiler	and specify -xlang=f95.

	  If you are mixing parallel Fortran objects with C++
	  objects, the link line must specify the -mt flag.


     -xlibmil
	  Synonym for -libmil.


     -xlibmopt
	  Use library of optimized math	routines

	  Use a	library	of selected math routines optimized for
	  performance.	This option usually generates faster
	  code.	It might produce slightly different results; if
	  so, they usually differ in the last bit.  The	order on
	  the command line for this library option is not
	  significant.

	  Default rounding mode, -fround=nearest, is assumed and
	  required when	using this option.


     -xlicinfo
	  (Obsolete) This option is silently ignored by	the
	  compiler.


     -xlic_lib=sunperf
	  Link with the	Sun Performance	Library

	  Example:
	     f95 -o pgx	-fast pgx.f -xlic_lib=sunperf

	  As with -l it	should appear after all	source and object
	  file names on	the command line. This option must be
	  used to link with the	Oracle Performance Library.


     -xlinkopt[=level]
	  (SPARC) Perform link-time optimizations on relocatable
	  object files.

	  The post-optimizer performs a	number of advanced
	  performance optimizations on the binary object code at
	  link-time. The value level sets the level of
	  optimizations	performed, and must be 0, 1, or	2.

	  The optimization levels are:
	  0	The post-optimizer is disabled.	(This is the
		default.)
	  1	Perform	optimizations based on control flow
		analysis, including instruction	cache coloring
		and branch optimizations, at link time.
	  2	Perform	additional data	flow analysis, including
		dead-code elimination and address computation
		simplification,	at link	time.

	  Specifying -xlinkopt without a level parameter implies
	  -xlinkopt=1.

	  These	optimizations are performed at link time by
	  analyzing the	object binary code. The	object files are
	  not rewritten	but the	resulting executable code might
	  differ from the original object codes.

	  This option is most effective	when used to compile the
	  whole	program, and with profile feedback.

	  When compiling in separate steps, -xlinkopt must appear
	  on both compile and link steps:

	    % f95 -c -xlinkopt a.f95 b.f95
	    % f95 -o myprog -xlinkopt=2	a.o b.o

	  Note that the	level parameter	is only	used when the
	  compiler is linking. In the example above, the post-
	  optimization level used is 2 even though the object
	  binaries were	compiled with an implied level of 1.

	  For -xlinkopt	to be useful, at least some, but not
	  necessarily all, of the routines in the program must be
	  compiled with	this option.  The optimizer can	still
	  perform some limited optimizations on	object binaries
	  not compiled with -xlinkopt.

	  -xlinkopt will optimize code coming from static
	  libraries that appear	on the compiler	command	line, but
	  it will skip and not optimize	code coming from shared
	  (dynamic) libraries that appear on the command line.
	  You can also use -xlinkopt when building shared
	  libraries (compiling with -G ).

	  The link-time	post-optimizer is most effective when
	  used with run-time profile feedback. Profiling reveals
	  the most and least used parts	of the code and	directs
	  the optimizer	to focus its effort accordingly.  This is
	  particularly important with large applications where
	  optimal placement of code performed at link time can
	  reduce instruction cache misses.  Typically, this would
	  be compiled as follows:

	  % f95	-o progt -xO5 -xprofile=collect:profdir	file.f95
	  % progt
	  % f95	-o prog	-xO5 -xprofile=use:prog	-profdir -xlinkopt file.f95

	  For details on using profile feedback, see -xprofile

	  Note that compiling with this	option will increase link
	  time slightly. Object	file sizes will	also increase,
	  but the size of the executable remains the same.
	  Compiling with -xlinkopt and -g increases the	size of
	  the executable by including debugging	information.


     -xloopinfo
	  Synonym for -loopinfo


     -xmaxopt[=n]
	  Enable optimization pragma and set maximum optimization
	  level.

	  Limits the optimization level	specified by a !$PRAGMA
	  SUN OPT=m directive to n.  When a directive specifying
	  a level m greater than n on the -xmaxopt flag	appears,
	  the compiler will use	n.

	  The value n corresponds to the values	1 through 5 of
	  the -O optimization level flag. The value of n must be
	  greater or equal to the value	of highest optimization
	  level	specified by other options. So,	for example:

	     f95 ... -O3 -xmaxopt=4

	  would	be appropriate.

	  The flag -xmaxopt by itself defaults to -xmaxopt=5
     -xmemalign[=ab]
	  (SPARC) Specify maximum assumed memory alignment and
	  behavior of misaligned data accesses.

	  For memory accesses where the	alignment is determinable
	  at compile time, the compiler	will generate the
	  appropriate load/store instruction sequence for that
	  alignment of data.

	  For memory accesses where the	alignment cannot be
	  determined at	compile	time, the compiler must	assume an
	  alignment to generate	the needed load/store sequence.

	  The -xmemalign flag allows the user to specify the
	  maximum memory alignment of data to be assumed by the
	  compiler in these indeterminable situations. It also
	  specifies the	error behavior to be followed at run-time
	  when a misaligned memory access does take place.

	  VALUES:

	  If a value is	specified, it must consist of two parts:
	  a numerical alignment	value, a, and an alphabetic
	  behavior flag, b.

	  Allowed values for alignment,	a are:

	  1	Assume at most 1 byte alignment.
	  2	Assume at most 2 byte alignment.
	  4	Assume at most 4 byte alignment.
	  8	Assume at most 8 byte alignment.
	  16	Assume at most 16 byte alignment.

	  Allowed values for behavior, b are:

	  i	Interpret access and continue execution.
	  s	Raise signal SIGBUS.
	  f	For all	SPARC 64-bit platforms,	raise signal
		SIGBUS for alignments less than	or equal to 4,
		otherwise interpret access and continue
		execution.  For	all other -xarch values, the f
		flag is	equivalent to i.

	  Defaults:

	  The first default, which applies when	no -xmemalign
	  flag appears,	is:

	     -xmemalign=8i on 32-bit SPARC platforms
	     -xmemalign=8s on 64-bit SPARC platforms for C and
	     C++
	     -xmemalign=8f on 64-bit SPARC platforms for Fortran

	  The second default, which applies when -xmemalign
	  appears but without a	value, is:

	     -xmemalign=1i for all platforms

	  Note that -xmemalign itself does not force a particular
	  data alignment. See -dalign or -aligncommon.

	  You must also	specify	-xmemalign whenever you	link to
	  an object file that was compiled with	a value	of b
	  either i or f.


     -xmodel=[a]
	  (x86)	Specify	the data address model for shared objects
	  on Solaris x64 platforms.

	  The -xmodel option enables the compiler to create 64-
	  bit shared objects for the Solaris x64 platforms and
	  should only be specified for the compilation of such
	  objects.

	  This option is valid only when -m64 is also specified
	  on 64-bit enabled x64	processors.

	  a is one of the following:

	  small
	       This option generates code for the small	model in
	       which the virutal address of code executed is
	       known at	link time and all symbols are known to be
	       located in the virtual addresses	in the range from
	       0 to 2^31 - 2^24	- 1.

	  kernel
	       Generates code for the kernel model in which all
	       symbols are defined to be in the	range from 2^64	-
	       2^31 to 2^64 - 2^24.

	  medium
	       Generates code for the medium model in which no
	       assumptions are made about the range of symbolic
	       references to data sections.  Size and address of
	       the text	section	have the same limits as	the small
	       code model. Applications	with large amounts of
	       static data might require -xmodel=medium	when
	       compiling with -m64.

	  If you do not	specify	-xmodel, the compiler assumes
	  -xmodel=small.  Specifying -xmodel without an	argument
	  is an	error.

	  It is	not neccessary to compile all routines with this
	  option as long as you	an ensure that objects being
	  accessed are within range.

	  Be aware that	not all	Linux system support the medium
	  model.

     -xnolib
	  Synonym for -nolib.


     -xnolibmil
	  Synonym for -nolibmil.


     -xnolibmopt
	  Cancel -xlibmopt

	  Use with -fast to cancel linking with	the optimized
	  math library.


     -xO[n]
	  Synonym for -O[n].


     -xopenmp[={parallel|noopt|none}]
	  Enable explicit parallelization with Fortran 95 OpenMP
	  version 2.5 directives.

	  The flag accepts the following suboption keywords:

	  parallel
	       Enables recognition of OpenMP pragmas.  The
	       minimum optimization level for -xopenmp=parallel
	       is -xO3.	 The compiler changes the optimization
	       from a lower level to -xO3 if necessary,	and
	       issues a	warning.

	  noopt
	       Enables recognition of OpenMP pragmas without
	       rasing the optimization level.

	       If you compile with an optimization level and
	       -xopenmp=noopt, it must be -xO3 or higher,
	       otherwise a compilation error is	issued.

	       If you do not specify an	optimization level with
	       -xopenmp=noopt, the OpenMP pragmas are recognized,
	       the program is parallelized accordingly,	but no
	       optimization is done.

	  none
	       Disables	recognition of OpenMP pragmas, the
	       optimization level is not changed, and no OpenMP-
	       related preprocessor strings are	defined.  (This
	       is the default when -xopenmp is not specified.)

	  -xopenmp specified without a suboption keyword is
	  equivalent to	-xopenmp=parallel.  This default could
	  change in future releases.  You can avoid warning
	  messages by explicitly specifying an optimization level
	  with -xopenmp.

	  Sub-options parallel,	or noopt will define the _OPENMP
	  preprocessor macro to	be the decimal value yyyymm where
	  yyyy and mm are the year and month designations of the
	  version of the OpenMP	API that the implementation
	  supports.  Refer to the Solaris Studio OpenMP	API
	  User's Guide for the value of	the _OPENMP macro for a
	  particular release.

	  Sub-options parallel and noopt will invoke -stackvar
	  automatically.

	  When debugging OpenMP	programs with dbx, compile with
		-g -xopenmp=noopt
	  to be	able to	breakpoint within parallel regions and
	  display the contents of variables.

	  To run a parallelized	program	in a multithreaded
	  environment, you must	set the	OMP_NUM_THREADS
	  environment variable prior to	execution. This	variable
	  tells	the runtime system the maximum number of threads
	  the program can create. The default is 1.  In	general,
	  set OMP_NUM_THREADS to the available number of virtual
	  processors on	the running system, which can be
	  determined by	using the Solaris psrinfo(1) command.

	  To enable nested parallelism,	you must set the
	  OMP_NESTED environment variable to TRUE. Nested
	  parallelism is disabled by default. See the Solaris
	  Studio OpenMP	API User's Guide chapter on nested
	  parallelism for details.

	  When compiling and linking in	separate steps,	include
	  -xopenmp on the link step as well. This is especially
	  important when compiling dynamic (.so) libraries. The
	  same release of the compiler should be used to compile
	  libraries that contain OpenMP	directives as the
	  programs that	reference these	libraries.

	  For bgest performance	and functionality, make	sure that
	  the latest patch of the OpenMP runtime library,
	  libmtsk.so, is installed on the running system.

	  The Fortran 95 OpenMP	is described in	the Solaris
	  Studio OpenMP	API User's Guide.


     -xpad
	  Synonym for -pad


     -xpagesize=n
	  Set the preferred page size for the stack and	the heap.

	  The n	value must be one of the following:

	  On SPARC:
	   8K 64K 512K 4M 32M 256M 2G 16G or default.

	  On x86:
	   4K 2M 4M 1G or default.

	  You must specify a valid page	size for the Solaris OS
	  on the target	platform, as returned by getpagesize(3C).
	  If you do not	specify	a valid	page size, the request is
	  silently ignored at run-time.	The Solaris OS offers no
	  guarantee that the page size request will be honored.

	  Note:	1G support on x86/x64 platforms	was added with
	  Solaris 10 5/08.  Compiler support was introduced in
	  Sun Studio 12	patch 126498-02.


	  You can use pmap(1) or meminfo(2) to determine page
	  size of the target platform.

	  If you specify -xpagesize=default, the flag is ignored.
	  -xpagesize without an	argument is the	equivalent to
	  -xpagesize=default.

	  This option is a macro for
	      -xpagesize_heap=n	-xpagesize_stack=n

	  These	two options accept the same arguments as
	  -xpagesize.  You can set them	both with the same value
	  by specifying	-xpagesize=n or	you can	specify	them
	  individually with different values.

	  Compiling with this flag has the same	effect as setting
	  the LD_PRELOAD environment variable to mpss.so.1 with
	  the equivalent options, or running the Solaris OS  9
	  command ppgsz(1) with	the equivalent options before
	  running the program.	See the	Solaris	OS man pages for
	  details.


     -xpagesize_heap=n
	  Set the page size in memory for the heap.

	  n is the same	as described for -xpagesize.
	   You must specify a valid page size for the Solaris OS
	  on the target	platform, as returned by
	  getpagesizes(3C).  If	you do not specify a valid page
	  size,	the request is silently	ignored	at run-time.

	  Note that this feature is not	available on Solaris OS	7
	  and 8	environments.

	  See -xpagesize for further details.


     -xpagesize_stack=n
	  Set the page size in memory for the stack.

	  n is the same	as described for -xpagesize.  You must
	  specify a valid page size for	the Solaris OS on the
	  target platform, as returned by getpagesizes(3C).  If
	  you do not specify a valid page size,	the request is
	  silently ignored at run-time.

	  Note that this feature is not	available on Solaris OS	7
	  and 8	environments.

	  See -xpagesize for further details.


     -xpec[={yes|no}]
	  Generate a PEC (Portable Executable Code) binary.

	  PEC binaries may be used with	Automatic Tuning System,
	  ATS. More information	about ATS is available here:
	  http://cooltools.sunsource.net/ats/index.html.

	  A binary built with -xpec is usually 5 to 10 times
	  larger than if it is built without.

	  The default is -xpec=no. Without an argument,	-xpec is
	  equivalent to	-xpec=yes.

     -xpentium
	  (x86)	Same as	-xtarget=pentium


     -xpg Synonym for -pg.

     -xpp={fpp|cpp}
	  Selects the source file preprocessor to be used with .F
	  .F95 .F03 files.

	  The default is fpp, which is appropriate for Fortran.
	  Previous versions of the compiler used cpp, the
	  standard C language preprocessor. To select cpp,
	  specify -xpp=cpp.


     -xprefetch[=a[,a]]
	  Enable and adjust prefetch instructions on those
	  architectures	that support prefetch.

	  a must be one	of the following values.


	  Value		 Meaning

	  auto		 Enable	automatic generation of	prefetch
			 instructions.


	  no%auto	 Disable automatic generation


	  explicit	 Enable	explicit prefetch directives


	  no%explicit	 Disable explicit prefectch directives.


	  latx:factor	 (SPARC) Adjust	the compiler's assumed
			 prefetch-to-load and prefetch-to-store
			 latencies by the specified factor.  The
			 factor	must be	a positive floating-point
			 or integer number.

			 The prefetch latency is the hardware
			 delay between the execution of	a
			 prefetch instruction and the time the
			 data being prefetched is available in
			 the cache.

			 The compiler assumes a	prefetch latency
			 value when determining	how far	apart to
			 place a prefetch instruction and the
			 load or store instruction that	uses the
			 prefetched data. Note - the assumed
			 latency between a prefetch and	a load
			 might not be the same as the assumed
			 latency between a prefetch and	a store.
			 The compiler tunes the	prefetch
			 mechanism for optimal performance across
			 a wide	range of machines and
			 applications. This tuning might not
			 always	be optimal. For	memory-intensive
			 applications, especially applications
			 intended to run on large
			 multiprocessors, you might be able to
			 obtain	better performance by increasing
			 the prefetch latency values. To increase
			 the values, use a factor that is greater
			 than 1	(one).	A value	between	.5 and
			 2.0 will most likely provide the maximum
			 performance.

			 For applications with datasets	that
			 reside	entirely within	the external
			 cache,	you might be able to obtain
			 better	performance by decreasing the
			 prefetch latency values.  To decrease
			 the values, use a factor that is less
			 than one.

			 To use	the latx:factor	suboption, start
			 with a	factor value near 1.0 and run
			 performance tests against the
			 application. Then increase or decrease
			 the factor, as	appropriate, and run the
			 performance tests again. Continue
			 adjusting the factor and running the
			 performance tests until you achieve
			 optimum performance. When you increase
			 or decrease the factor	in small steps,
			 you will see no performance difference
			 for a few steps, then a sudden
			 difference, then it will level	off
			 again.

	  yes		 Same as -xprefetch=auto,explicit. No
			 other suboptions may be specified.


	  no		 Same as -xprefetch=no%auto,no%explicit.
			 No other suboptions may be specified.


	  With -xprefetch, -xprefetch=auto, and	-xprefetch=yes,
	  the compiler is free to insert prefetch instructions
	  into the code	it generates. This can result in a
	  performance improvement on architectures that	support
	  prefetch.

	  Defaults:

	  If -xprefetch	is not specified,
	  -xprefetch=auto,explicit is assumed.

	  If only -xprefetch is	specified,
	  -xprefetch=auto,explicit is assumed.

	  If automatic prefetching is enabled, such as with
	  -xprefetch or	-xprefetch=yes,	but a latency factor is
	  not specified, then latx:1.0 is assumed.

	  Interactions:

	  With -xprefetch=explicit, the	compiler will recognize
	  the directives:
	     !$PRAGMA SUN_PREFETCH_READ_ONCE (address)
	     !$PRAGMA SUN_PREFETCH_READ_MANY (address)
	     !$PRAGMA SUN_PREFETCH_WRITE_ONCE (address)
	     !$PRAGMA SUN_PREFETCH_WRITE_MANY (address)

	  The -xchip setting effects the determination of the
	  assumed latencies and	therefore the result of	a
	  latx:factor setting.

	  The latx:factor suboption is valid only when automatic
	  prefetching is enabled. That is, latx:factor is ignored
	  unless it is used with auto.

	  Warnings:

	  Explicit prefetching should only be used under special
	  circumstances	that are supported by measurements.

	  Because the compiler tunes the prefetch mechanism for
	  optimal performance across a wide range of machines and
	  applications,	you should only	use the	latx:factor
	  suboption when the performance tests indicate	there is
	  a clear benefit. The assumed prefetch	latencies might
	  change from release to release. Therefore, retesting
	  the effect of	the latency factor on performance
	  whenever switching to	a different release is highly
	  recommended.

     -xprefetch_auto_type=[no%]indirect_array_access
	  Generate indirect prefetches for a data arrays accessed
	  indirectly.

	  [no%]indirect_array_access
	  Does [not] generate indirect prefetches for the loops
	  indicated by the option -xprefetch_level=[1|2|3] in the
	  same fashion the prefetches for direct memory	accesses
	  are generated.

	  If you do not	specify	a setting for
	  -xprefetch_auto_type,	the compiler sets it to
	  -xprefetch_auto_type=no%indirect_array_access.

	  Requires -xprefetch=auto and an optimization level -xO3
	  or higher.

	  Options such as -xdepend can affect the aggressiveness
	  of computing the indirect prefetch candidates	and
	  therefore the	aggressiveness of the automatic	indirect
	  prefetch insertion due to better memory alias
	  disambiguation information.


     -xprefetch_level=n
	  Control the degree of	insertion of prefetch
	  instructions.

	  This option is effective only	when compiling with
	  -xprefetch=auto, with	optimization level 3 or	greater
	  (-xO3), and on a platform that supports prefetch.

	  n may	be 1, 2, or 3.

	  The default with -xprefetch=auto is level 2.

	  Prefetch level 2 finds additional opportunities for
	  prefetch instructions	than level 1. Prefetch level 3
	  finds	additional prefetch instructions than level 2.

	  Prefetch levels 2 and	3 may not be effective on older
	  SPARC	and x86	platforms.


     -xprofile=p
	  Collects data	for a profile or use a profile to
	  optimize.

	  p must be collect[:profdir], use[:profdir], or
	  tcov[:profdir]

	  This option causes execution frequency data to be
	  collected and	saved during execution,	then the data can
	  be used in subsequent	runs to	improve	performance.
	  Profile collection is	safe for multithreaded
	  applications.	That is, profiling a program that does
	  its own multitasking ( -mt ) produces	accurate results.
	  This option is only valid when you specify -xO2 or
	  greater level	of optimization.

	  If compilation and linking are performed in separate
	  steps, the same -xprofile option must	appear on the
	  compile as well as the link step.  See the Fortran
	  User's Guide for a complete list of options that must
	  be specified at both compile time and	link time.

	  collect[:profdir]
	       Collects	and saves execution frequency for later
	       use by the optimizer with -xprofile=use.	The
	       compiler	generates code to measure statement
	       execution-frequency.

	       -xMerge -ztext -xprofile=collect	should not be
	       used together.	While -xMerge forces statically
	       initialized data	into read-only storage,	-ztext
	       prohibits position-dependent symbol relocations in
	       read-only storage, and -xprofile=collect	generates
	       statically initialized, position-dependent symbol
	       relocations in writable storage.

	       The profile directory name profdir, if specified,
	       is the pathname of the directory	where profile
	       data are	to be stored when a program or shared
	       library containing the profiled object code is
	       executed.  If the pathname is not absolute, it is
	       interpreted relative to the current working
	       directory when the program is compiled with the
	       option -xprofile=use:profdir.

	       If no profile directory name is specified, profile
	       data are	stored in a directory named
	       program.profile where program is	the basename of
	       the profiled process's main program.

	       Example[1]:  to collect and use profile data in
	       the directory myprof.profile located in the same
	       directory where the program is built:


	       f95 -xprofile=collect:myprof.profile -xO5 prog.f95 -o prog
		 ./prog
	       f95 -xprofile=use:myprof.profile	-xO5 prog.f95 -o prog


	       Example[2]:  to collect profile data in the
	       directory /bench/myprof.profile and later use the
	       collected profile data in a feedback compilation
	       at optimization level -xO5:

		f95 -xprofile=collect:/bench/myprof.profile -xO5 prog.f95 -o prog
		 ...run	prog from multiple locations...
	       f95 -xprofile=use:/bench/myprof.profile -xO5 prog.f95 -o	prog
	       You can set the environment variables SUN_PROFDATA
	       and SUN_PROFDATA_DIR to control where a program
	       compiled	with -xprofile=collect stores the profile
	       data. If	set, the -xprofile=collect data	is
	       written to SUN_PROFDATA_DIR/SUN_PROFDATA.

	       These environment variables similarly control the
	       path and	names of the profile data files	written
	       by tcov , as described in the tcov(1) man page.

	       If these	environment variables are not set, the
	       profile data is written to 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.

	       If you are compiling and	linking	in separate
	       steps, make sure	that any object	files compiled
	       with -xprofile=collect are also linked with
	       -xprofile=collect. For a	complete list of compiler
	       options that must be specified at both compile
	       time and	at link	time, see the C	User's Guide.

	       See also	the ENVIRONMENT	section	of this	man page
	       below for descriptions of environment variables
	       that control asynchronous profile collections.

	  use[:profdir]
	       Uses execution frequency	data collected from code
	       compiled	with -xprofile=collect[:profdir] to
	       optimize	for the	work performed when the	profiled
	       code was	executed.  profdir is the pathname of a
	       directory containing profile data collected by
	       running a program that was compiled with
	       -xprofile=collect[:profdir].

	       The profdir is optional.	If profdir is not
	       specified, the name of the executible binary is
	       used. a.out is used if -o is not	specified. The
	       compiler	looks for profdir.profile/feedback, or
	       a.out.profile/feedback without profdir specified.
	       For example:

		  f95 -xprofile=collect	-o myexe prog.f95
		  f95 -xprofile=use:myexe -xO5 -o myexe	prog.f95

	       The program is optimized	by using the execution
	       frequency data previously generated and saved in
	       the feedback files written by a previous	execution
	       of the program compiled with -xprofile=collect.

	       Except for the -xprofile	option,	the source files
	       and other compiler options must be exactly the
	       same as those used for the compilation that
	       created the compiled program which in turn
	       generated the feedback file.  The same version of
	       the compiler must be used for both the collect
	       build and the use build as well.

	       If compiled with	-xprofile=collect:profdir, the
	       same profile directory name profdir must	be used
	       in the optimizing compilation:
	       -xprofile=use:profdir.


	       See also	-xprofile_ircache for speeding up
	       compilation between collect and use phases.


	  tcov[:profdir]
	       Instrument object files for basic block coverage
	       analysis	using tcov(1).

	       If the optional :profdir	argument is specified,
	       the compiler will create	a profile directory at
	       the specified location.	The data stored	in the
	       profile directory can be	used either by tcov(1) or
	       by the compiler with -xprofile=use:profdir .

	       If the optional :profdir	argument is omitted, a
	       profile directory will be created when the
	       profiled	program	is executed.  The data stored in
	       the profile directory can only be used by tcov(1).
	       The location of the profile directory can be
	       controlled using	environment variables
	       SUN_PROFDATA and	SUN_PROFDATA_DIR. See ENVIRONMENT
	       below.

	       If the location specified by :profdir is	not an
	       absolute	pathname, it is	interpreted at
	       compilation time	relative to the	directory in
	       which the current object	file is	to be written.
	       If :profdir is specified	for any	object file, the
	       same location must be specified for all object
	       files in	the same program.  The directory whose
	       location	is specified by	:profdir must be
	       accessible from all machines where the profiled
	       program is to be	executed.  The profile directory
	       should not be deleted until its contents	are no
	       longer needed, because data stored there	by the
	       compiler	cannot be restored except by
	       recompilation.

	       Example 1: if object files for one or more
	       programs	are compiled with
	       -xprofile=tcov:/test/profdata, a	directory named
	       /test/profdata.profile will be created by the
	       compiler	and used to store data describing the
	       profiled	object files.  The same	directory will
	       also be used at execution time to store execution
	       data associated with the	profiled object	files.

	       Example 2: if a program named "myprog" is compiled
	       with -xprofile=tcov and executed	in the directory
	       /home/joe, the directory	/home/joe/myprog.profile
	       will be created at run time and used to store
	       runtime profile data.


     -xprofile_ircache[=path]
	  (SPARC) Save and reuse compilation data between collect
	  and use profile phases.

	  Use with -xprofile=collect|use to improve compilation
	  time during the use phase by reusing compilation data
	  saved	from the collect phase.

	  If specified,	path will override the location	where the
	  cached files are saved. By default, these files will be
	  saved	in the same directory as the object file.
	  Specifying a path is useful when the collect and use
	  phases happen	in two different places.

	  A typical sequence of	commands might be:

	    f95	-xO5 -xprofile=collect -xprofile_ircache t1.f95	t2.f95
	    a.out    //	run collects feedback data
	    f95	-xO5 -xprofile=use -xprofile_ircache t1.f95 t2.f95

	  With large programs, compilation time	in the use phase
	  can improve significantly by saving the intermediate
	  data in this manner. But this	will be	at the expense of
	  disk space, which could increase considerably.

     -xprofile_pathmap=collect_prefix:use_prefix
	  (SPARC) Set path mapping for profile data files.

	  Use the -xprofile_pathmap option with	the -xprofile=use
	  option.

	  Use -xprofile_pathmap	when the compiler is unable to
	  find profile data for	an object file that is compiled
	  with -xprofile=use, and:

	  o  You are compiling with -xprofile=use
	     into a directory that is not the directory	used when
	     previously	compiling with -xprofile=collect.

	  o  Your object files share a common base name	in the profile
	     but are distinguished from	each other by their
	     location in different directories.

	  The collect-prefix is	the prefix of the UNIX path name
	  of a directory tree in which object files were compiled
	  using	-xprofile=collect.

	  The use-prefix is the	prefix of the UNIX path	name of	a
	  directory tree in which object files are to be compiled
	  using	-xprofile=use.

	  If you specify multiple instances of -xprofile_pathmap,
	  the compiler processes them in the order of their
	  occurrence.  Each use-prefix specified by an instance
	  of -xprofile_pathmap is compared with	the object file
	  path name until either a matching use-prefix is
	  identified or	the last specified use-prefix is found
	  not to match the object file path name.


     -xrecursive
	  Allow	routines defined without RECURSIVE attribute to
	  call themselves recursively.

	  Normally, only subprograms defined with the RECURSIVE
	  attribute can	call themselves	recursively.

	  Compiling with -xrecursive enables subprograms to call
	  themselves recursively even if they are not defined
	  with the attribute RECURSIVE.	 But, unlike the
	  RECURSIVE attribute, this flag does not cause	local
	  variables to be allocated on the stack by default.  For
	  each recursive invocation of the subprogram to have
	  separate values for local variables, compile with
	  -stackvar to put local variables on the stack.

	  Compiling routines with -xrecursive can cause
	  performance degradations.


     -xreduction
	  Synonym for -reduction


     -xregs=r[,r...]
	  Specify the usage of registers for the generated code.

	  r is a comma-separated list of one or	more of	the
	  following suboptions:	 appl, float, frameptr.

	  Prefixing a suboption	with no% disables that suboption.

	  Example:  -xregs=appl,no%float

	  Note that -xregs suboptions are restricted to	specific
	  hardware platforms.

	  appl (SPARC)
		   Allow the compiler to generate code using the
		   application registers as scratch registers.
		   The application registers are:

		   g2, g3, g4 (on 32-bit platforms)
		   g2, g3 (on 64-bit platforms)

		   It is strongly recommended that all system
		   software and	libraries be compiled using
		   -xregs=no%appl. System software (including
		   shared libraries) must preserve these
		   registers' values for the application. Their
		   use is intended to be controlled by the
		   compilation system and must be consistent
		   throughout the application.

		   In the SPARC	ABI, these registers are
		   described as	application registers. Using
		   these registers can increase	performance
		   because fewer load and store	instructions are
		   needed. However, such use can conflict with
		   some	old library programs written in	assembly
		   code.

		   For more information	on SPARC instruction
		   sets, see -xarch.

	  float	(SPARC)
		   Allow the compiler to generate code by using
		   the floating-point registers	as scratch
		   registers for integer values. Use of
		   floating-point values may use these registers
		   regardless of this option. To generate binary
		   code	free of	all references to floating point
		   registers, use -xregs=no%float and make sure
		   your	source code does not in	any way	use
		   floating point types.

	  frameptr (x86)
		   Allow the compiler to use the frame-pointer
		   register (%ebp on IA32, %rbp	on x86 64-bit
		   platforms) as a general-purpose register.

		   The default is -xregs=no%frameptr.

		   The C++ compiler ignores -xregs=frameptr
		   unless exceptions are  also disabled	with
		   -features=no%except.	 Note also that
		   -xregs=frameptr is part of -fast, but is
		   ignored by the C++ compiler unless
		   -features=no%except is also specified.

		   With	-xregs=frameptr	the compiler is	free to
		   use the frame-pointer register to improve
		   program performance.	However, some features of
		   the debugger	and performance	measurement tools
		   may be limited. Stack tracing, debuggers, and
		   performance analyzers cannot	report on
		   functions compiled with -xregs=frameptr.

		   Also, C++ calls to Posix pthread_cancel() will
		   fail	trying to find cleanup handlers.

		   Mixed C, Fortran, and C++ code should not be
		   compiled with -xregs=frameptr if a C++
		   function, called directly or	indirectly from	a
		   C or	Fortran	function, can throw an exception.
		   If compiling	such mixed source code with
		   -fast, add -xregs=no%frameptr after the -fast
		   option on the command line.

		   With	more available registers on 64-bit
		   platforms, compiling	with -xregs=frameptr has
		   a better chance of improving	32-bit code
		   performance than 64-bit code.

		   Note:  -xregs=frameptr is ignored and a
		   warning is issued by	the compiler if	you also
		   specify -xpg.

	  The SPARC default is -xregs=appl,float.
	  The x86 default is -xregs=no%frameptr.
	  -xregs=frameptr is included in the expansion of -fast
	  on x86.

	  It is	strongly recommended that you compile code
	  intended for shared libraries	that will link with
	  applications,	with -xregs=no%appl,float.  At the very
	  least, the shared library should explicitly document
	  how it uses the application registers	so that
	  applications linking with those libraries are	aware of
	  these	register assignments.

	  For example, an application using the	registers in some
	  global sense (such as	using a	register to point to some
	  critical data	structure) would need to know exactly how
	  a library with code compiled without -xregs=no%appl is
	  using	the application	registers in order to safely link
	  with that library.



     -xs Allow debugging by dbx	without	object files.

	 This option causes all	the debug information to be
	 copied	into the executable.  There is little impact on
	 dbx performance or the	run-time performance of	the
	 program, but it does take more	disk space.

	 With -xs, if you move executables to another directory,
	 then you can use dbx and ignore the object (.o) files.
	 Use this option in case you cannot retain the .o object
	 files.


     -xsafe=mem
	 (SPARC) Allow the compiler to assume that no memory
	 protection violations occur.

	 This option allows the	compiler to use	the non-faulting
	 load instruction in the SPARC V9 architecture.

	 Warnings:
	 Because non-faulting loads do not cause a trap	when a
	 fault such as address misalignment or segmentation
	 violation occurs, you should use this option only for
	 programs in which such	faults cannot occur.  Because few
	 programs incur	memory-based traps, you	can safely use
	 this option for most programs.	 Do not	use this option
	 for programs that explicitly depend on	memory-based
	 traps to handle exceptional conditions.

	 Interactions:
	 This option takes effect only when used with
	 optimization level -xO5 and one of the	following -xarch
	 values: sparc,	sparcvis, sparcvis2, sparcvis3,	for both
	 -m32, and -m64.


     -xsb
	 Synonym for -sb.  (Obsolete and ignored).

     -xsbfast
	 Synonym for -sbfast.  (Obsolete and ignored).


     -xspace
	 Do not	increase code size

	 Do no optimizations that increase the code size.
	 Example: Do not unroll	loops.


     -xtarget=t
	 Specify the target system for the instruction set and
	 optimization.

	 t must	be one of: native, native64, generic, generic64,
	 platform-name.

	 The -xtarget option permits a quick and easy
	 specification of the -xarch, -xchip, and -xcache
	 combinations that occur on real systems. The only
	 meaning of -xtarget is	in its expansion.

	 The -xtarget values are:

	 native:  Get the best performance on the host system
	 (32-bit architecture).	 Expands to:
	 -m32 -xarch=native -xchip=native -xcache=native

	 native64:  This is obsolete. Use -xtarget=native -m64
	 instead.

	 generic:  Get the best	performance for	most 32-bit
	 platforms This	is the default and expands to:
	 -m32 -xarch=generic -xchip=generic -xcache=generic

	 generic64:  This is obsolete. Use -xtarget=generic -m64
	 instead.

	 platform-name:	 Get the best performance for the
	 specified platform.

	 Valid SPARC platform names are	shown below.

	 Commonly used platform	names:
	     ultra, ultra2, ultra2i, ultra1/140, ultra1/170,
	     ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300,
	     ultra2/2170, ultra2/2200, ultra2/2300, ultra2e,
	     ultra2i, ultra3, ultra3cu,	ultra3i, ultra4,
	     ultra4plus, ultraT1 ultraT2, ultraT2plus, ultraT3,
	     sparc64vi,	sparc64vii.

	 Compiling for a 64-bit	Solaris	OS on UltraSPARC V9
	 platforms is indicated	by the -m64 flag. If -xtarget is
	 specified, the	-m64 option must also appear, as in:
	    -xtarget=ultra2 ...	-m64
	 otherwise a 32-bit memory model will be used.

	 On x86	systems, the valid platform names are:	generic,
	 native, pentium, pentium_pro, pentium3, pentium4,
	 woodcrest, penryn, nehalem, barcelona,	and opteron.

	 Compiling for 64-bit Solaris OS on 64-bit x86 AMD
	 Opteron platforms is indicated	by the -m64 flag, as in:.
	     -xtarget=opteron -m64
	 otherwise the compilation will	revert to 32-bit x86.

	 See the Fortran User's	Guide for the -xtarget expansions
	 showing the actual -xarch -xchip -xarch values	used for
	 each platform name.

	 This option is	a macro. Each specific value for -xtarget
	 expands into a	specific set of	values for the -xarch,
	 -xchip, and -xcache options. For example:
	 -xtarget=ultra4 is equivalent to:
	 -xarch=sparcvis -xcache=64/32/4:8192/128/2 -xchip=ultra4

	 To determine the expansion of any -xtarget platform name
	 on a running system, execute the command

	 f95 -xtarget=platform_name -dryrun |& grep ###

	 For example:

	  f95 -dryrun -xtarget=ultra4 |& grep ###
	 ###	 command line files and	options	(expanded):
	 ### -dryrun -xarch=sparcvis -xcache=64/32/4:8192/128/2	-xchip=ultra4

	 Note that -xtarget for	a specific host	platform might
	 not expand to the same	-xarch,	-xchip,	or -xcache
	 settings as -xtarget=native when compiling on that
	 platform.


     -xtime
	 Synonym for -time.


     -xtypemap=spec
	 Specify default data mappings.

	 This option provides a	flexible way to	specify	the byte
	 sizes for default data	types.

	 The syntax of the string spec is:

	 type:bits,type:bits,...

	 The allowable data types are REAL, DOUBLE, INTEGER.  The
	 data sizes accepted are 16, 32, 64, and 128.

	 This option applies to	all variables declared without
	 explicit byte sizes, as in REAL XYZ.

	 The allowable combinations are:

	   real:32
	   real:64
	   double:64
	   double:128
	   integer:16
	   integer:32
	   integer:64

	 A useful mapping is:

	    -xtypemap=real:64,double:64,integer:64

	 which maps REAL and DOUBLE to 8 bytes,	but does not
	 promote DOUBLE	PRECISION to QUAD PRECISION.

	 Note also that	INTEGER	and LOGICAL are	treated	the same,
	 and COMPLEX is	mapped as two REAL data	elements. Also,
	 DOUBLE	COMPLEX	will be	treated	the way	DOUBLE is mapped.
	 For more information, see the Fortran User's Guide



     -xunroll=n
	 Synonym for -unroll=n



     -xvector[=a]
	 Enables automatic generation of calls to the vector
	 library and/or	the generation of the SIMD (Single
	 Instruction Multiple Data) instructions. You must use
	 default rounding mode by specifying -fround=nearest when
	 you use this option.

	 The -xvector option requires optimization level -xO3 or
	 greater. Compilation will not proceed if the
	 optimization level is unspecified or lower than -xO3,
	 and a message is issued.

	 a is the equivalent of	the following:
	 [no%]lib
	      (SOLARIS Only) Does [not]enable 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.

	 [no%]simd
	      Does [not]direct 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.	The suboption no%simd can be used
	      to disable it.

	      The compiler will	use SIMD only if streaming
	      extensions exist in the target architecture; that
	      is, if target ISA	is at least SSE2. For example,
	      you can specify -xtarget=woodcrest,
	      -xarch=generic64,	-xarch=sse2, -xarch=sse3, or
	      -fast on a modern	platform to use	it. If the target
	      ISA has no streaming extensions, the suboption will
	      have no effect.

	 yes  This option is deprecated, specify -xvector=lib
	      instead.

	 no   This option is deprecated, specify -xvector=none
	      instead.

	 The default is	-xvector=simd on x86 and -xvector=%none
	 on SPARC platforms.  If you specify -xvector without a
	 suboption, the	compiler assumes -xvector=simd,lib on
	 x86, -xvector=lib on SPARC (Solaris), and -xvector=simd
	 (Linux).

	 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=lib at compile time, you
	 must also specify it at link time.


     -xvpara
	 Synonym for -vpara


     -ztext
	 Make no library with relocations
	 Do not	make the library if relocations	remain.	 The
	 general purpose of -ztext is to verify	that the
	 generated library is pure text; instructions are all
	 position-independent code. Therefore, it is generally
	 used with both	-G and -pic.

	 With -ztext, if ld finds an incomplete	relocation in the
	 text segment, then it does not	build the library. If it
	 finds one in the data segment,	then it	generally builds
	 the library anyway; the data segment is writeable.

	 Without -ztext, ld builds the library,	relocations or
	 not.

	 A typical use is to make a library from both source
	 files and object files, where you do not know if the
	 object	files were made	with -pic.


	 -ztext	-xprofile=collect should not be	used together.
	 -ztext	prohibits position-dependent symbol relocations
	 in read-only storage, and -xprofile=collect generates
	 statically initialized, position-dependent symbol
	 relocations in	writable storage.

     Other arguments are taken to be either linker option
     arguments,	or names of f95-compatible object programs,
     typically produced	by an earlier run, or libraries	of
     routines that are f95-compatible.	These programs,	together
     with the results of any compilations specified, are linked
     in	the order given	to produce an executable program in the
     file specified by the -o option, or in a file named a.out if
     the -o option is not specified.


FILE SUFFIXES

     Files with	the following suffixes may appear on the compiler
     command line. The suffix usually identifies the type of the
     file and determines how the compiler processes it.

     .f	.for
	  Fixed	format Fortran source files.

     .f90 .f95 .f03
	  Free format Fortran 90, Fortran 95, or Fortran 2003
	  source files.

     .F	  Fixed	format Fortran source containing preprocessor
	  directives. These files are preprocessed by fpp(1)
	  before they are compiled. (See also the -xpp=	option.)

     .F90 .F95 .F03
	  Free format Fortran 95 source	containing preprocessor
	  directives.  These files are preprocessed fpp(1) before
	  they are compiled.  (See also	the -xpp= option.)

     .s	  Assembler source files.

     .il  Inline assembler expansion code template files.  Used
	  by the compiler to expand calls to selected routines
	  into inline code.  See the inline(1) man page	and -
	  inline option	flag for more information on inline
	  template files.

     .o	  Object files to be passed to the linker.

     .so  Shared object	files or libraries to be passed	to the
	  linker.

     .a	  Library files	passed to the linker, or searched for
	  MODULE subprograms (see the -M option	flag.)

     .mod Files	containing precompiled MODULE program units.
	  These	are generated by the compiler.	See the	-M option
	  flag.


DIRECTIVES

     General Directives:  f95 allows general compiler directive
     lines starting with C$PRAGMA, (in fixed-format only), or
     !$PRAGMA, and either uppercase or lowercase is allowed.

       !$PRAGMA	C(list_of_subprogram_names)
       !$PRAGMA	SUN UNROLL n
       !$PRAGMA	WEAK function_name
       !$PRAGMA	SUN OPT=n
       !$PRAGMA	PIPELOOP=n
       !$PRAGMA	SUN_PREFETCH_READ_ONCE (name)
       !$PRAGMA	SUN_PREFETCH_READ_MANY (name)
       !$PRAGMA	SUN_PREFETCH_WRITE_ONCE	(name)
       !$PRAGMA	SUN_PREFETCH_WRITE_MANY	(name)
       !$PRAGMA	IGNORE_TKR list
       !$PRAGMA	ASSUME (expression [, probability])

     Parallelization Directives:  f95 recognizes the OpenMP API
     parallelization directives. OpenMP	is the recommended model
     for explicit parallelization for all the Solaris Studio
     compilers.

     In	this release, the f95 compiler accepts Version 2.5 of the
     OpenMP Fortran 95 API. These have the sentinel !OMP.

     For detailed information on the Solaris Studio OpenMP
     implementation, see the OpenMP API	User's Guide.



ENVIRONMENT

     The paths shown below assume the root of the Solaris Studio
     software installation is indicated	by <install-directory>.
     Contact your system administrator to determine the	actual
     path.

  PATH
     To	use f95, add the following to the start	of the search
     path:

     <install-directory>/bin/


  MANPATH
     To	access the f95 man pages, add the following to the
     MANPATH environment variable:

     <install-directory>/man/


  MODDIR
     Specifies the path	to the directory where the compiler will
     write .mod	module files.  See also	-moddir, which takes
     precedence	over the setting of the	MODDIR environment
     variable.


  LD_LIBRARY_PATH
     Generally,	you need not set up LD_LIBRARY_PATH.  If you do
     need to do	so, then maybe there is	some discrepancy in the
     installation, or some executable has been built incorrectly.

     Set the LD_LIBRARY_PATH, environment variable to:

     <install-directory>/lib/


  LD_LIBRARY_PATH_64
     Like the LD_LIBRARY_PATH environment variable,
     LD_LIBRARY_PATH_64	sets the path for searching for	64-bit
     libraries.

     When running in a 64-bit enabled Solaris OS and linking in
     32-bit mode, LD_LIBRARY_PATH_64 is	ignored.  If only
     LD_LIBRARY_PATH is	defined, it us used for	both 32-bit and
     64-bit linking.  If both LD_LIBRARY_PATH and
     LD_LIBRARY_PATH_64	are defined, the 32-bit	linking	will be
     done using	LD_LIBRARY_PATH	and the	64-bit linking using
     LD_LIBRARY_PATH_64.

     See Linker	and Libraries Guide for	more information on these
     environment variables.

  LD_RUN_PATH
     If	you use	LD_RUN_PATH, note that for f95,	LD_RUN_PATH is
     not identical with	-R.  (For ld.so, they are identical.)
     See -R, in	the Fortran User's Guide, for details.


  STACKSIZE
     You can set the stack size	to be used by each slave thread
     in	a multithreaded	program	by giving the STACKSIZE
     environment variable a value (in Kilobytes):
	% setenv STACKSIZE 8192
     sets the stack size for each slave	thread to 8 Mb.

     The default thread	stack size on 32-bit systems is	4
     megabytes.	On 64-bit systems it is	8 megabytes.

     The STACKSIZE environment variable	also accepts numerical
     values with a suffix of either B, K, M, or	G for bytes,
     kilobytes,	megabytes, or gigabytes	respectively.  The
     default is	kilobytes. (Note that the term "kilobyte"
     actually means 1024 bytes.)

     See the Fortran Programming Guide chapter on Parallelizaion
     for details.


  SUNW_MP_WARN
     Controls warning messages issued by the OpenMP runtime
     library. If set TRUE the library issues warning messages to
     stderr. Set FALSE disables	warnings. The default is FALSE.


  SUNW_MP_THR_IDLE
     Controls end-of-task status of each helper	thread and can be
     set to SPIN, or SLEEP ns. Default is SLEEP.  See the OpenMP
     API User's	Guide for details on these and other OpenMP
     environment variables .


  OMP_NUM_THREADS
     Sets the number of	threads	to use during application
     execution.	See the	OpenMP API User's Guide	for details on
     these and other OpenMP environment	variables .

  TMPDIR
     The compiler normally creates temporary files in the
     directory /tmp. You may specify another directory by setting
     the environment variable TMPDIR to	your chosen directory.
     (If TMPDIR	isn't a	valid directory, the compiler will use
     /tmp). The	-temp option has precedence over the TMPDIR
     environment variable.

  SUN_PROFDATA=profdir
     If	set, store profile data	collected from a program compiled
     with -xprofile=collect in a directory named profdir in the
     current working directory at the time that	the program is
     executed.	If the optional	argument :profdir was specified
     in	-xprofile=collect[:profdir] at compilation time,
     SUN_PROFDATA as no	effect.


  SUN_PROFDATA_DIR=dirname
     If	set, store profile data	collected from a program compiled
     with -xprofile=collect in a directory whose UNIX dirname is
     dirname.  If dirname is not absolute, it is interpreted
     relative to the current working directory at the time that
     the program is executed.  If the optional argument	:profdir
     was specified in -xprofile=collect[:profdir] at compilation
     time, SUN_PROFDATA_DIR has	no effect.


  SUN_PROFDATA_ASYNC_INTERVAL=async_interval
     Set this environment variable to enable asynchronous profile
     collection.  In asynchronous profile collection, profile
     data are collected	from a running process at regular
     intervals whose duration is specified in units of seconds.

     SUN_PROFDATA_ASYNC_INTERVAL has no	effect unless one of the
     environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64
     is	set to /usr/lib/{,64}/libxprof_audit.so.1.

     Asynchronous profile collection requires an MT-safe, mmap
     based memory allocator, such as libumem(3)	with mmap-based
     allocation	specified by setting UMEM_OPTIONS to
     backend=mmap.

     Example: to enable	asynchronous profile collection	from a 64
     bit process at 1 minute intervals,specify the following
     environment variables:

     $ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
       SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap	\
       64-bit-program [program-args]

     Asynchronous profile collection requires OpenSolaris 2009.06
     or	later.


  SUN_PROFDATA_ASYNC_VERBOSE=verbose
     If	set nonzero, enables verbose messages from asynchronous
     collector to stderr.  SUN_PROFDATA_ASYNC_VERBOSE has no
     effect unless asynchronous	profile	collection is enabled.


  SUN_PROFDATA_REPLACE={objfile,program,all}
     SUN_PROFDATA_REPLACE indicates the	scope of profile data to
     be	reset when a changed version of	an object file is
     detected at runtime.  Use SUN_PROFDATA_REPLACE to ensure
     that profile data are consistent with the profiled	program
     within the	specified unit of program scope.

	  The values of	SUN_PROFDATA_REPLACE and their meanings
	  are as follows:

	  objfile
	       reset profile data of changed object file

	  program
	       reset profile data of all object	files in program
	       containing changed object file

	  all  reset entire contents of	profile	directory if any
	       object file has changed

	  The default setting of SUN_PROFDATA_REPLACE is
	  SUN_PROFDATA_REPLACE=objfile .

	  Example:
	  % setenv SUN_PROFDATA_REPLACE	program	(csh)
	  $ export SUN_PROFDATA_REPLACE=program	(ksh)

	  With this setting, when a program containing a changed
	  object file is executed, all object files in the
	  program will have their profile data reset.  Relevant
	  options include -xOn and -xipo=n.




FILES

     See the section FILE SUFFIXES above for files identified by
     their name	suffix that may	appear on the compiler command
     line.

     In	addition, the compiler uses the	following files:

     /usr/lib/libc.so
	  Standard C system library
     /usr/lib/libm.so
	  Standard system math library
     /tmp/*
	  Compiler temporary files
     mon.out
	  File produced	for analysis by	prof(1)
     gmon.out
	  File produced	for analysis by	gprof(1)



     The following reside in the Solaris Studio	installation
     directory,	as indicated by	<install-directory>.

     <install-directory>/bin/fpp
	  Fortran preprocessor
     <install-directory>/bin/cpp
	  C preprocessor
     <install-directory>/prod/include/f95/
	  Path searched	for f95	INCLUDE	statement
     <install-directory>/prod/include/f95/floatingpoint.h
	  f95 IEEE arithmetic type definitions

     The following libraries may exist in both .so and .a
     versions:	Note: Mixing static and	shared Fortran runtime
     libraries should be avoided; always link with the latest
     shared Fortran libraries.

     libfsu
	  f95 support intrinsics
     libfui
	  f95 -	UNIX interface
     libfio
	  Fortran 95 I/O
     libf*ai
	  Fortran 95 array intrinsics libraries
     libifai
	  Fortran 95 interval array intrinsics library
     libf77compat
	  f77 Fortran 77 compatibility library
     libsunmath
	  Solaris Studio math lib
     libsunimath
	  Solaris Studio interval math lib
     xprof_fini.o
	  Initialization and finalization handlers for programs
	  compiled with	-xprofile=collect


NOTES

     For Solaris release 10, new shared	libraries libxprof.so.1,
     libxprof_audit.so.1, and libtdf.so.1 must be installed in
     order to use the -xprofile	option.	These libraries	are pre-
     installed on the latest OpenSolaris and Solaris releases.


READMEs

     A number of README	files provide valuable last-minute
     information on Solaris Studio compilers and tools and
     libraries.	Of particular interest are:

	  o   fortran_95
	  o   math_libraries
     The Solaris Studio	readmes	for this release can be	found on
     the Solaris Studio	portal at:
     http://developers.sun.com/sunstudio/documentation


SEE ALSO

     An	index to the complete Solaris Studio documentation can be
     found by pointing an HTML browser at the following	URL:
	http://developers.sun.com/sunstudio/documentation

     Consult the following man pages for additional information:
     asa(1),  cc(1),  dbx(1),  fpp(1),	fpr(1),	 fsplit(1),
     gprof(1),	ld(1),	perror(3f),  prof(1),  tcov(1)

     Consult the following manuals for detailed	information:
     Fortran User's Guide
     Fortran Programming Guide
     OpenMP API	User's Guide
     Numerical Computation Guide
     Studio Performance	Analyzer
     Fortran Library Reference
     Solaris OS	Linker and Libraries Guide
     Debugging a Program With dbx
     Sun Performance Library User's Guide:  This Solaris Studio
     release includes the Sun Performance Library containing
     subroutines and functions for operations in computational
     linear algebra and	Fourier	transforms.

     You can find much more information	on the Solaris Studio
     Developer Network web site:
     http://developers.sun.com/sunstudio/



DIAGNOSTICS

     The diagnostics produced by f95 itself are	intended to be
     self-explanatory. Occasional messages can be produced by the
     linker.