© 2009 Advanced Micro Devices, Inc.
Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being “GNU General Public License” and “Funding Free Software”, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled “GNU Free Documentation License”.
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.
This manual documents how to use the x86 Open64 compilers, as well as their features and incompatibilities, and how to report bugs. It corresponds to x86 Open64 version 4.2.2.
This manual does not include the internals of the Open64 compiler. The x86 Open64 Compiler Suite lets you build and optimize C, C++, and Fortran applications for the Linux® OS (operating system). The x86 Open64 Compiler Suite is designed to be used on the command line. Through out this user guide the x86 Open64 Compiler Suite may be referred to as ”Open64” or ”Open64 compilers”.
The x86 Open64 compiler system is designed to generate code for x86, AMD64 (AMD x86-64 Architecture), and Intel64 (Intel x86-64 Architecture) applications. The x86 Open64 environment provides the developer the necessary options when building and optimizing C, C++, and Fortran applications targeting 32-bit and 64-bit Linux® platforms.
The x86 Open64 compiler system offers a high level of advance optimizations, multi-threading, and processor support that includes global optimization, vectorization, interprocedural analysis, feedback directed optimizations, loop transformations, and micro-architecture-specific code generation.
IA-32 applications (32-bit) can run on all x86, AMD64, and Intel64 based Linux systems. x86-64 applications (64-bit) can only run on AMD64 or Intel64 based Linux systems.
For more information about the compiler features and other components, see the Release Notes.
Open64 is an integrated distribution of compilers for three major programming languages: C, C++, and Fortran. Open64 has been retargeted to a number of x86 architectures. The language-independent component of Open64 includes the majority of the optimizers, as well as the 'code generators' that generate machine code for various processors (e.g. AMD64, IA-32, Intel64).
The part of a compiler that is specific to a particular language is called the 'front-end'. In addition to the front-ends that are integrated components of Open64, there are several other front ends that are maintained separately e.g., the Fortran front-end.
The C preprocessor is an integral feature of the C/C++ programming languages.
This documentation assumes that you are familiar with the C, C++, and Fortran programming languages and with your processor's architecture. You should also be familiar with the host computer's operating system.
Each compiler is invoked using its own compiler driver. The C compiler is invoked using opencc, the C++ compiler is invoked using openCC, and Fortran is invoked using openf90. When we talk about compiling one of those languages, we might refer to that compiler by its own name, or as Open64. Either is correct.
Historically, compilers for many languages, including C++ and Fortran, have been implemented as “preprocessors” which emit another high level language such as C. None of the compilers included in Open64 are implemented this way; they all generate machine code directly. This sort of preprocessor should not be confused with the C preprocessor, which is an integral feature of the C, C++, and Fortran languages.
For each language compiled by Open64 for which there is a standard, Open64 attempts to follow one or more versions of that standard, possibly with some exceptions, and possibly with some extensions.
Open64 supports three versions of the C standard, although support for the most recent version is not yet complete.
The original ANSI C standard (X3.159-1989) was ratified in 1989 and published in 1990. This standard was ratified as an ISO standard (ISO/IEC 9899:1990) later in 1990. There were no technical differences between these publications, although the sections of the ANSI standard were renumbered and became clauses in the ISO standard. This standard, in both its forms, is commonly known as C89, or occasionally as C90, from the dates of ratification. The ANSI standard, but not the ISO standard, also came with a Rationale document. To select this standard in Open64, use one of the options -ansi, -std=c89 or -std=iso9899:1990; to obtain all the diagnostics required by the standard, you should also specify -pedantic (or -pedantic-errors if you want them to be errors rather than warnings). See Options Controlling C Dialect.
Errors in the 1990 ISO C standard were corrected in two Technical Corrigenda published in 1994 and 1996. Open64 does not support the uncorrected version.
An amendment to the 1990 standard was published in 1995. This
amendment added digraphs and __STDC_VERSION__ to the language,
but otherwise concerned the library. This amendment is commonly known
as AMD1; the amended standard is sometimes known as C94 or
C95. To select this standard in Open64, use the option
-std=iso9899:199409 (with, as for other standard versions,
-pedantic to receive all required diagnostics).
A new edition of the ISO C standard was published in 1999 as ISO/IEC 9899:1999, and is commonly known as C99. Open64 has incomplete support for this standard version; see http://gcc.gnu.org/gcc-4.2/c99status.html for details. To select this standard, use -std=c99 or -std=iso9899:1999. (While in development, drafts of this standard version were referred to as C9X.)
Errors in the 1999 ISO C standard were corrected in two Technical Corrigenda published in 2001 and 2004. Open64 does not support the uncorrected version.
For references to Technical Corrigenda, Rationale documents and information concerning the history of C that is available online, see http://gcc.gnu.org/readings.html
By default, Open64 provides some extensions to the C language that on rare occasions conflict with the C standard. Use of the -std options listed above will disable these extensions where they conflict with the C standard version selected. You may also select an extended version of the C language explicitly with -std=gnu89 (for C89 with GNU extensions) or -std=gnu99 (for C99 with GNU extensions). The default, if no C language dialect options are given, is -std=gnu89; this will change to -std=gnu99 in some future release when the C99 support is complete. Some features that are part of the C99 standard are accepted as extensions in C89 mode.
The Open64 C++ compiler conforms to ISO/IEC 14882: 1998(E), Programming Languages-C++ standard.
The Open64 C/C++ compiler generates code which complies with:
The Open64 Fortran compiler complies with the ISO/IEC 1539-1:1997 (Fortran 95) standards. The compiler is also able to compile essentially all standard-compliant Fortran 90 and Fortran 77 programs. It also supports the ISO/IEC TR-15581 enhancements to allocatable arrays, and the OpenMP Application Program Interface v2.5 specification. The Open64 Fortran compiler conforms to:
The Open64 Fortran compiler also: supports legacy FORTRAN 77 (i.e. ANSI X3.9-1978) programs, ABI compatible with GNU FORTRAN 77 programs, and generates code which complies with the x86-32 ABI and x86-64 ABI.
Although Open64 Fortran focuses on implementing the Fortran 95 standard for the time being, a few Fortran 2003 features are currently available. These include partial comformance with ISO/IEC 1539-1:2004 (Fortran 2003) Programming Languages-Fortran.
AMD Technical Support is available to x86 Open64 AMD platform developers, for more information please visit http://developer.amd.com/cpu/open64/. The x86 Open64 compiler can be downloaded and supported from the AMD Developer Central Web Site.
Available to the developer, at the x86 Open64 website, is x86 Open64 compiler information, including:
AMD provides support of the x86 Open64 Compiler Suite distrubuted by AMD on a limited bases. AMD'’s product offering is comprised of x86 Open64 compilers and libraries. This applies to current and past x86 Open64 releases distrubuted by AMD, depending on release life cycle. If you think you have found a bug in x86 Open64, please report it following the instructions in Bug Reporting.
AMD Technical Support provides services to customers using the x86 Open64 compiler to develop or port applications to AMD platforms within an enterprise Linux environment. AMD offers specialized support to the developer throughout the development and test cycle of their application. For further information on AMD Technical Support, see the x86 Open64 Technical Support Guide and Service Level Agreement at http://developer.amd.com/cpu/open64/.
For detailed information on host system requirements, see the x86 Open64 Installation Guide and/or the Release Notes.
Your bug reports play an essential role in making x86 Open64 reliable.
When you encounter a problem, the first thing to do is to see if it is already known. If it isn't known, then you should report the problem.
If you are not sure whether you have found a bug, here are some guidelines:
asm statement), that is a compiler bug, unless the
compiler reports errors (not just warnings) which would ordinarily
prevent the assembler from being run.
However, you must double-check to make sure, because you may have a program whose behavior is undefined, which happened by chance to give the desired results with another C/C++ or Fortran compiler.
For example, in many nonoptimizing compilers, you can write x;
at the end of a function instead of return x;, with the same
results. But the value of the function is undefined if return
is omitted; it is not a bug when Open64 produces different results.
Problems often result from expressions with two increment operators,
as in f (*p++, *p++). Your previous compiler might have
interpreted that expression the way you intended; Open64 might
interpret it another way. Neither compiler is wrong. The bug is
in your code.
After you have localized the error to a single source line, it should be easy to check for these things. If your program is correct and well defined, you have found a compiler bug.
Bugs should be reported to the x86 Open64 bug database. Please refer to
http://developer.amd.com/cpu/open64
for up-to-date instructions regarding how to submit bug reports. Copies of this file in HTML (bugs.html) and plain text (BUGS) are also part of x86 Open64 releases.
If you would like to help pretest Open64 releases to assure they work well, current development sources are available by SVN see:
http://developer.amd.com/cpu/open64.
Source and binary snapshots are also available for download see:
http://developer.amd.com/cpu/open64.
If you would like to work on improvements to Open64, please read the advice at these URLs:
http://www.open64.net/home.html
http://www.open64.net/about-open64.html
for information on how to make useful contributions and avoid duplication of effort. Suggested projects are listed at:
http://wiki.open64.net/index.php/Main_Page.
The x86 Open64 Compiler Suite uses the GCC front-ends to handle programs written in C and C++. Programs written in Fortran use the SGI/Cray front-end. The C/C++ and Fortran front-ends interface to a common back-end for code optimization and code generation components. Once your programs are compiled, linked and the executable file is produced, you can then execute or evaluate your application on the target system. The language your program is written in determines which compiler driver (or command-line) you should use to invoke the required compiler.
The x86 Open64 C compiler is invoked by the command:
$ opencc <input files>
The x86 Open64 C++ compiler is invoked by the command:
$ openCC <input files>
By default, input files to the C/C++ compiler will be preprocessed using the preprocessor. This default behavior can be overridden by specifying the switch -nocpp.
You can also specify other options or switches to the C/C++ compiler. See x86 Open64 Option Summary, for a list of these options and switches.
For example, to explicitly control the optimization level used by the compiler:
$ opencc -Ofast main.c foo.c
or
$ opencc -c -ipa main.c
$ opencc -c -ipa foo.c
$ opencc -ipa main.o foo.o
The C/C++ compiler predefines certain macros for the preprocessor. Follow these steps to find out what these macros are:
For example:
$ opencc -dD -keep foo.c
$ cat foo.i
The x86 Open64 Fortran compiler is invoked by the command:
$ openf90 <input files>
or
$ openf95 <input files>
By default, input files with suffixes of .F or .f are treated as fixed-form files, whereas input files with suffixes of .F90, .f90, .F95, or .f95 are treated as free-form files. This default behavior can be overridden by specifying the switches -fixedform or -freeform.
By default, input files with suffixes of .F, .F90, or .F95 will be preprocessed using the C preprocessor. This default behavior can be overridden by specifying the switches -cpp or -ftpp.
You can also specify other options or switches to the Fortran compiler. See x86 Open64 Option Summary, for a list of these options and switches.
For example, to explicitly control the optimization level used by the compiler:
$ openf90 -Ofast main.f sub.f
or
$ openf90 -c -ipa main.f
$ openf90 -c -ipa sub.f
$ openf90 -ipa main.o sub.o
The Fortran compiler predefines certain macros for the preprocessor. Depending on which preprocessor is used, different macros are pre-defined. Follow these steps to find out what these macros are:
If the C preprocessor is used (-cpp):
For example:
$ openf90 -Wp,-dD -E foo.f -cpp > foo.i
$ cat foo.i
If the Fortran preprocessor is used (-ftpp):
Only the following macros are pre-defined:
LANGUAGE_FORTRAN 1
LANGUAGE_FORTRAN90 1
_LANGUAGE_FORTRAN90 1
unix 1
__unix 1
After a Fortran module is compiled, the compiler generates a file called foo.mod (where foo is the name of the module). By default this file is placed in the same directory where the compilation command is issued. This default behavior can be overridden by specifying the switch -module.
When compiling a Fortran file that uses the foo module, by default the Fortran compiler will look for the file foo.mod in the same directory where the compilation command is issued. This default behavior can be overridden by specifying the switch -Idirectory.
Files containing modules that are to be used by other files must be compiled before the other files. This can be accomplished by any or all of the following:
After the Fortran compiler compiles a file containing a module, the compiler generates an object file (.o) as well as the module information file (.mod), even if the file contains nothing other than just the module. This object file must be linked with the rest of the program to generate an executable.
When you invoke x86 Open64, it normally does preprocessing, compilation, assembly and linking. The “overall options” allow you to stop this process at an intermediate stage. For example, the -c option says not to run the linker. Then the output consists of object files output by the assembler.
Other options are passed on to one stage of processing. Some options control the preprocessor and others the compiler itself. Yet other options control the assembler and linker; most of these are not documented here, since you rarely need to use any of them.
Most of the command line options that you can use with Open64 are useful for C programs; when an option is only useful with another language (usually C++), the explanation says so explicitly. If the description for a particular option does not mention a source language, you can use that option with all supported languages.
See Compiling C++ Programs, for a summary of special options for compiling C++ programs.
The opencc program accepts options and file names as operands. Many options have multi-letter names; therefore multiple single-letter options may not be grouped: -dr is very different from -d -r.
You can mix options and other arguments. For the most part, the order you use doesn't matter. Order does matter when you use several options of the same kind; for example, if you specify -L more than once, the directories are searched in the order specified.
Many options have long names which start with -f or with -W—for example, -funsafe-math-optimizations, -Wformat and so on. Options of the form -fflag specify machine-independent flags. Most of these have both positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual typically documents only one of these two forms, whichever one is not the default or the one you typically will use. You can figure out the other form by either removing no- or adding it.
See Option Index, for an index to Open64's options.
Here is a summary of all the options, grouped by type. Explanations are in the following sections.
-c -S -E -o file -copyright -help -help:string
-keep -LIST: -LIST:all_options -LIST:notes -LIST:options -LIST:symbols
-r -show -show-defaults -show0 -showt -dumpversion -v -version -###
-Idir -iquotedir -isystemdir -Ldir
-nostdinc -isysrootdir
-ansi -fgnu-keywords -fno-gnu-keywords -fms-extensions
-fno-builtin -fno-common -fprefix-function-name -fpack-struct
-fshort-double -fshort-enums -fshort-wchar -f[no-]signed-bitfields
-f[no-]signed-char -f[no-]strict-aliasing -gnuN
-std=standard -traditional
-fabi-version=N -f[no-]check-new -f[no-]exceptions
-f[no-]gnu-exceptions -f[no-]rtti -fuse-cxa-atexit
-ansi -auto-use module_name -byteswapio -colN
-convert conversion -d-lines -default64 -exten-source
-noextend-source -nog77mangle -pad-char-literals -rreal_spec -uname
-LANG:copyinout -LANG:formal_deref_unsafe -LANG:global_asm
-LANG:heap_allocation_threshold -LANG:IEEE_minus_zero -LANG:IEEE_save
-LANG:recursive -LANG:rw_const _LANG:short_circuit_conditionals
-alignN -backslash -f[no-]unwind-tables -finhibit-size-directive
-fpic fPIC -fno-ident -HP -HUGEPAGE -HP:bdt -HP:heap
-HUGEPAGE:bdt -HUGEPAGE:heap -ignore-suffix -opencc -no-opencc
-nobool -U name
Options that Control Feedback Directed Optimizations
-fb-create -fb-opt -fb-phase -finstrument-functions
Options that Control Glogal Optimizations
-apo -O0 -O1 -O2 -O3 -Os -Ofast
-WOPT:aggstr -WOPT:const_pre -WOPT:if_conv -WOPT:ivar_pre
-WOPT:mem_opnds -WOPT:retype_expr -WOPT:unroll -WOPT:val
Options that Control General Optimizations
-f[no-]fast-math -ffloat-store -fno-math-errno
-f[no-]unsafe-math-optimizations -m87-precision -noexpopt
-openmp -mp -OPT:alias -OPT:align_unsafe -OPT:asm_memory
-OPT:bb -OPT:cis -OPT:cyg_instr -OPT:div_split -OPT:early_mp
-OPT:early_intrinsics -OPT:fast_bit_intrinsics -OPT:fast_complex
-OPT:fast_exp -OPT:fast_io -OPT:fast_math -OPT:fast_nint
-OPT:fast_sqrt -OPT:fast_stdlib -OPT:fast_trunc -OPT:fold_reassociate
-OPT:fold_unsafe_relops -OPT:fold_unsigned_relops -OPT:goto
-OPT:IEEE_arithmetic -OPT:IEEE_NaN_inf -OPT:inline_intrinsics
-OPT:keep_ext -OPT:malloc_algorithm -OPT:malloc_alg
-OPT:Ofast -OPT:Olimit -OPT:pad_common -OPT:recip -OPT:reorg_common
-OPT:roundoff -OPT:ro -OPT:rsqrt -OPT:space -OPT:speculate
-OPT:transform_to_memlib -OPT:treeheight -OPT:unroll_analysis
-OPT:unroll_level -OPT:unroll_times_max -OPT:unroll_size
-OPT:wrap_around_unsafe_opt
Options that Control Interprocedural Optimizations
-f[no-]implicit-inline-templates -f[no-]implicit-templates
-f[no-]inline -inline -INLINE -noinline -f[no-]inline-functions
-fkeep-inline-functions -INLINE:all -INLINE:aggressive
-INLINE:list -INLINE:must -INLINE:never -INLINE:none -INLINE:preempt
-ipa -IPA -IPA:addressing -IPA:aggr_cprop -IPA:alias -IPA:callee_limit
-IPA:cgi -IPA:clone_list -IPA:common_pad_size _IPA:cprop -IPA:ctype
-IPA:depth -IPA:dfe -IPA:dve -IPA:echo -IPA:field_reorder
-IPA:forcedepth -IPA:ignore_lang -IPA:inline -IPA:keeplight
-IPA:linear -IPA:map_limit -IPA:maxdepth -IPA:max_jobs -IPA:min_hotness
-IPA:multi_clone -IPA:node_bloat -IPA:plimit -IPA:pu_reorder
-IPA:relopt -IPA:small_pu -IPA:sp_partition -IPA:space -IPA:specfile
-IPA:use_intrinsic
Options that Control Loop Nest Optimizations
-LNO:apo_use_feedback -LNO:build_scalar_reductions -LNO:blocking
-LNO:blocking_size -LNO:fission -LNO:full_unroll -LNO:fu
-LNO:full_unroll_size -LNO:full_unroll_outer -LNO:fusion
-LNO:fusion_peeling_limit -LNO:gather_scatter -LNO:hoistif
-LNO:ignore_feedback -LNO:ignore_pragmas -LNO:local_pad_size
-LNO:minvariant -LNO:minvar -LNO:non_blocking_loads -LNO:oinvar
-LNO:opt -LNO:ou_prod_max -LNO:outer -LNO:outer_unroll_max
-LNO:ou_max -LNO:parallel_overhead -LNO:prefetch -LNO:prefetch_ahead
-LNO:prefetch_verbose -LNO:processors -LNO:sclrze -LNO:simd
-LNO:simd_reduction -LNO:simd_verbose -LNO:svr_phase1
-LNO:trip_count_assumed_when_unknown -LNO:trip_count -LNO:vintr
-LNO:vintr_verbose -LNO:interchange -LNO:unswitch
-LNO:unswitch_verbose -LNO:outer_unroll -LNO:ou -LNO:outer_unroll_deep
-LNO:ou_deep -LNO:outer_unroll_further -LNO:ou_further
-LNO:outer_unroll_max -LNO:ou_max -LNO:pwr2 -LNO:assoc
-LNO:cmp -LNO:cs -LNO:is_mem -LNO:ls -LNO:ps -LNO:tlb -LNO:tlbcmp
-LNO:tlbdmp -LNO:assume_unknown_trip_count -LNO:pf -LNO:prefetch
-LNO:prefetch_ahead -LNO:prefetch_manual
-A predicate -A -predicate -C -cpp -dD -DI -dM -dN
-Dname -Dvar -fcoco -fe -f[no-]preprocessed -ftpp
-M -macro-expand -MD -MDtarget -MDupdate -MF -MG -MM -MMD -MP
-MQ -MT -nocpp -no-gcc -P -Uname -Wp,option
-fno-asm -Wa,option
-ar -c -S -E -f[no-]fast-stdlib -H -llibrary
-objectlist -nostartfiles -nodefaultlibs -nostdinc -nostdinc++
-nostdlib -shared -shared-libgcc -static-libgcc -static --static
-static-data -stdinc -symbolic -Xlinker -Wl,option
-CG:cflow -CG:cmp_peep -CG:compute_to -CG:cse_regs -CG:gcm
-CG:inflate_reg_request -CG:load_exe -CG:local sched_alg -CG:locs_best
-CG:locs_reduce_prefetch -CG:locs_shallow_depth -CG:movnti -CG:p2align
-CG:p2align_freq -CG:post_local_sched -CG:pre_local_sched
-CG:prefer_legacy_regs -CG:prefetch -CG:ptr_load_use
-CG:push_pop_int_saved_regs -CG:sse_cse_regs -CG:unroll_fb_req
-CG:use_prefetchnta -CG:use_test -GRA:home -GRA:optimize_boundary
-GRA:prioritize_by_density -GRA:unspill
-TENV:frame_pointer -TENV:simd_dmask -TENV:simd_imask
-Tenv:simd_omask -TENV:simd_pmask -TENV:simd_umask
-TENV:simd_zmask -TENV:X
-march -mtune -mcpu -m[no-]sse -m[no-]sse2
-m[no-]sse3 -m[no-]sse4a -m[no-]3dnow -m32 -m64 -mcmodel
-C -clist -CLIST: -CLIST:dotc_file -CLIST:doth_file
-CLIST:emit_pfetch -CLIST:linelength -CLIST:show -flist
-FLIST: -FLIST:ansi_format -FLIST:emit_pfetch -FLIST:ftn_file
-FLIST:linelength -FLIST:show -f[no-]permissive -fullwarn
-pedantic-errors -trapuv -zerouv
-dD -dI -dM -dN -fprofile-arcs -frandom-seed
-ftest-coverage -g -g0 -g1 -g2 -g3 -gdwarf-2 -gdwarf-20
-gdwarf-21 -gdwarf-22 -gdwarf-23 -p -pg -profile
-w -Wall -Wbad-function-cast -W[no-]deprecated
-W[no-]disabled-optimization -W[no-]div-by-zero -W[no-]endif-labels
-W[no-]error -W[no-]float-equal -W[no-]import -W[no-]larger-than
-Wno-deprecated-declarations -woff -woffall -woffoptions -woffnum
-Wundef -Wno-undef -W[no-]uninitialized -W[no-]unknown-pragmas
-W[no-]unreachable-code -W[no-]unused -W[no-]unused_function
-W[no-]unused-label -W[no-]unused-parameter -W[no-]unused-value
-W[no-]unused-variable -W[no-]write-strings
Warning Options for C/C++ Only
-Waggregate-return -W[no-]cast-align -W[no-]char-subscripts
-W[no-]comment -W[no-]conversion -Wno-declaration-after-statement
-W[no-]format -W[no-]format-nonliteral -W[no-]format-security
-w[no-]-id-clash -W[no-]implicit -W[no-]implicit-function-declaration
-W[no-]implicit-int -W[no-]inline -W[no-]main -W[no-]missing-braces
-W[no-]missing-declarations -W[no-]missing-format-attribute
-W[no-]missing-noreturn -W[no-]missing-prototypes -W[no-]multichar
-W[no-]nested-externs -Wno-cast-qual -Wno-format-extra-args
-Wno-format-y2k -Wnonnull -Wno-non-template-friend
-W[no-]non-virtual-dtor -Wno-pmf-conversions -W[no-]old-style-cast
-W[no]overloaded-virtual -W[no-]packed -W[no-]padded -W[no-]parentheses
-W[no-]pointer-arith -W[no-]redundant-decls -W[no-]redundant-decls
-W[no-]reorder -W[no-]return-type -W[no-]sequence-point -W[no-]shadow
-W[no-]sign-compare -W[no-]sign-promo -W[no-]strict-aliasing
-W[no-]strict-prototypes -W[no-]switch -Wswitch-default -Wswitch-enum
-W[no-]system-headers -W[no-]synth -W[no-]traditional -W[no-]trigraphs
Some command line options provide a group of suboptions. The x86 Open64 compiler supports a number of these group options, for example:
-CG:-CLIST:-FLIST:-GRA:-HUGEPAGE:-INLINE:-IPA:-LANG:-LIST:- LNO:-OPT:-TENV:-WOPT:Group options accept several suboptions allowing the user to specify a setting for each suboption. The general usage format is:
-GROUP_OPTION:question=answer
To specify multiple suboptions:
The following command lines are equivalent:
% opencc -LIST:notes=ON -LIST:symbols=OFF foo.c
% opencc -LIST:notes=ON:symbols=OFF foo.c
Some answer to suboptions to group options are specified with a setting that either enables or disables the feature. To enable a feature, specify the suboption either alone or with =1, =ON, or =TRUE. To disable a feature, specify the suboption with either =0, =OFF, or =FALSE. The following command lines are equivalent:
% opencc -OPT:recip=ON:space=OFF:speculate=TRUE foo.c
% opencc -OPT:recip:space=0:speculate=ON foo.c
Note for brevity, this document uses only the ON|OFF settings to suboptions. The compiler also accepts 1|0 and TRUE|FALSE as settings.
Group options -INLINE: and -IPA: have noted differences for the GROUP_OPTION without any suboptions. Additionally specifying:
Compilation can involve up to four stages: preprocessing, compilation proper, assembly and linking, always in that order. x86 Open64 is capable of preprocessing and compiling several files either into several assembler input files, or into one assembler input file; then each assembler input file produces an object file, and linking combines all the object files (those newly compiled, and those specified as input) into an executable file.
For any given input file, the file name suffix determines what kind of compilation is done:
If you only want some of the stages of compilation, you can use filename suffixes to tell the compiler where to start, and one of the options -c, -S, or -E to say where the compiler is to stop.
-cBy default, the object file name for a source file is made by replacing the suffix .c, .i, .s, etc., with .o.
Unrecognized input files, not requiring compilation or assembly, are
ignored. Not to be used with -r since the -c option
nullifies the -r option.
-SBy default, the assembler file name for a source file is made by replacing the suffix .c, .i, etc., with .s.
Input files that don't require compilation are ignored.
-EInput files which don't require preprocessing are ignored. The-E option nullifies the -nocpp option.
-o fileIf -o is not specified, the default is to put an executable
file in a.out, the object file for
source.suffix in source.o, its
assembler file in source.s, a precompiled header file in
source.suffix.gch, and all preprocessed C source on
standard output.
-copyright-help-help:stringIf -help: is specified a description of the command line options that
contain a given string is printed.
-keepNote if IPA is enabled and the assembly language file is required (i.e.
filename.s), option -IPA:keeplight=OFF must be specified.
-LIST:question=answer-LIST:=ON|OFF-LIST:all_options=ON|OFF-LIST:notes=ON|OFF-LIST:options=ON|OFF-LIST:symbols=ON|OFF-r-show-show-defaultsFor C/C++ -show-defaults will also print the compatible gcc version.
-show0-showt-dumpversion-v-version-###These options specify directories to search for header files, for libraries and for parts of the compiler. Note the space between the option and the directory name, dir, is not required (e.g., L dir is equivalent to Ldir).
-I dirThe -I is used for the following types of files:
INCLUDE statement of the Fortran source programs.
#include statement of a preprocessing directives.
USE statements.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. The directory will still be searched but as a system directory at its normal position in the system include chain. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
The compiler searches for files in the following order:
-iquote dir-isystem dir-L dir-nostdinc-isysroot dirC++ source files conventionally use one of the suffixes .C, .cc, .cpp, or .cxx; C++ header files often use .hh or .H; and preprocessed C++ files use the suffix .ii. x86 Open64 recognizes files with these names and compiles them as C++ programs even if you call the compiler the same way as for compiling C programs (usually with the name opencc).
However, the use of opencc does not add the C++ library. openCC is a program that calls x86 Open64 and treats .c, .h and .i files as C++ source files instead of C source files unless -x is used, and automatically specifies linking against the C++ library. This program is also useful when precompiling a C header file with a .h extension for use in C++ compilations.
When you compile C++ programs, you may specify many of the same command-line options that you use for compiling programs in any language; or command-line options meaningful for C and related languages; or options that are meaningful only for C++ programs. See Options Controlling C Dialect, for explanations of options for languages related to C and C++.
The following options control the dialect of C (or languages derived from C, such as C++) that the compiler accepts:
-ansiThis turns off certain features of x86 Open64 that are incompatible with ISO
C90 (when compiling C code), or of standard C++ (when compiling C++ code),
such as the asm and typeof keywords.
It also enables the undesirable and rarely used ISO trigraph feature.
For the C compiler, it disables recognition of C++ style //
comments as well as the inline keyword.
The alternate keywords __asm__, __extension__,
__inline__ and __typeof__ continue to work despite
-ansi. You would not want to use them in an ISO C program, of
course, but it is useful to put them in header files that might be included
in compilations done with -ansi.
The -ansi option does not cause non-ISO programs to be rejected gratuitously. For that, -pedantic is required in addition to -ansi. See Warning Options.
The macro __STRICT_ANSI__ is predefined when the -ansi
option is used. Some header files may notice this macro and refrain
from declaring certain functions or defining certain macros that the
ISO standard doesn't call for; this is to avoid interfering with any
programs that might use these names for other things.
Functions that would normally be built in but do not have semantics
defined by ISO C (such as alloca and ffs) are not built-in
functions when -ansi is used.
-fgnu-keywords-fno-gnu-keywordstypeof as a keyword.
-fno-gnu-keywords specifies to not recognize typeof as a keyword,
so that code can use this word as an identifier.
You can use the keyword __typeof__ instead.
-ansi implies -fno-gnu-keywords.
The default is -fno-gnu-keywords.
-fms-extensionsSome cases of unnamed fields in structures and unions are only
accepted with this option.
-fno-builtin__builtin functions.
Open64 normally generates special code to handle certain built-in functions
more efficiently; for instance, calls to alloca may become single
instructions that adjust the stack directly, and calls to memcpy
may become inline copy loops. The resulting code is often both smaller
and faster, but since the function calls no longer appear as such, you
cannot set a breakpoint on those calls, nor can you change the behavior
of the functions by linking with a different library. In addition,
when a function is recognized as a built-in function, Open64 may use
information about that function to warn about problems with calls to
that function, or to generate more efficient code, even if the
resulting code still contains calls to that function. For example,
warnings are given with -Wformat for bad calls to
printf, when printf is built in, and strlen is
known not to modify global memory.
If you wish to enable built-in functions selectively when using -fno-builtin, you may define macros such as:
#define abs(n) __builtin_abs ((n))
#define strcpy(d, s) __builtin_strcpy ((d), (s))
-fno-commonextern) in
two different compilations, you will get an error when you link them.
The only reason this might be useful is if you wish to verify that the
program will work on other systems which always work this way.
-fprefix-function-name-fpack-struct[=n]Warning: the -fpack-struct switch causes the compiler to generate
code that is not binary compatible with code generated without that switch.
Additionally, it makes the code suboptimal.
Use it to conform to a non-default application binary interface.
-fshort-doubledouble as for float.
Warning: the -fshort-double switch causes the compiler to generate
code that is not binary compatible with code generated without that switch.
Use it to conform to a non-default application binary interface.
-fshort-enumsenum type only as many bytes as it needs for the
declared range of possible values. Specifically, the enum type
will be equivalent to the smallest integer type which has enough room.
Warning: the -fshort-enums switch causes the compiler to generate
code that is not binary compatible with code generated without that switch.
Use it to conform to a non-default application binary interface.
-fshort-wcharWarning: the -fshort-wchar switch causes the compiler to generate
code that is not binary compatible with code generated without that switch.
Use it to conform to a non-default application binary interface.
-fsigned-bitfields-fno-signed-bitfieldssigned or unsigned. By
default, such a bit-field is signed, because this is consistent; the
basic integer types such as int are signed types.
-fsigned-char-fno-signed-charchar be signed, like signed char.
Each kind of machine has a default for what char should
be. It is either like unsigned char by default or like
signed char by default.
Ideally, a portable program should always use signed char or
unsigned char when it depends on the signedness of an object.
But many programs have been written to use plain char and
expect it to be signed, or expect it to be unsigned, depending on the
machines they were written for. This option, and its inverse, let you
make such a program work with the opposite default.
The type char is always a distinct type from each of
signed char or unsigned char, even though its behavior
is always just like one of those two.
-fstrict-aliasing-fno-strict-aliasingunsigned int can alias an int, but not a
void* or a double. A character type may alias any other
type.
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type. So, the code above will work as expected. However, this code might not:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Every language that wishes to perform language-specific alias analysis
should define a function that computes, given a tree
node, an alias set for the node. Nodes in different alias sets are not
allowed to alias. For an example, see the C front-end function
c_get_alias_set.
Enabled at levels -O2, -O3, -Os.
-gnuN-std=standardThe compiler can accept several base standards, such as c89 or
c++98, and GNU dialects of those standards, such as
gnu89 or gnu++98. By specifing a base standard, the
compiler will accept all programs following that standard and those
using GNU extensions that do not contradict it. For example,
-std=c89 turns off certain features of GCC that are
incompatible with ISO C90, such as the asm and typeof
keywords, but not other GNU extensions that do not have a meaning in
ISO C90, such as omitting the middle term of a ?:
expression. On the other hand, by specifing a GNU dialect of a
standard, all features the compiler support are enabled, even when
those features change the meaning of the base standard and some
strict-conforming programs may be rejected. The particular standard
is used by -pedantic to identify which features are GNU
extensions given that version of the standard. For example
-std=gnu89 -pedantic would warn about C++ style //
comments, while -std=gnu99 -pedantic would not.
A value for this option must be provided; possible values are
-traditional
This section describes the command-line options that are only meaningful
for C++ programs; but you can also use most of the compiler options
regardless of what language your program is in. For example, you
might compile a file firstClass.C like this:
openCC -g -frepo -O -c firstClass.C
In this example, only -frepo is an option meant only for C++ programs; you can use the other options with any language supported by x86 Open64.
Here is a list of options that are only for compiling C++ programs:
-fabi-version=N (C++ Only)The default is -fabi-version=2 or version 2.
-fcheck-new (C++ Only)-fno-check-new (C++ Only)operator new is non-null
before attempting to modify the storage allocated. This check is
normally unnecessary because the C++ standard specifies that
operator new will only return 0 if it is declared
throw(), in which case the compiler will always check the
return value even without this option. In all other cases, when
operator new has a non-empty exception specification, memory
exhaustion is signalled by throwing std::bad_alloc. See also
new (nothrow). -fno-check-new instructs the compiler
to not check the result of operator new for null.
-fexceptions (C++ Only)-fno-exceptions (C++ Only)-fgnu-exceptions (C++ Only)-fno-gnu-exceptions (C++ Only)-frtti (C++ Only)-fno-rtti (C++ Only)void * or to
unambiguous base classes.
-fuse-cxa-atexit (C++ Only)__cxa_atexit function rather than the atexit function.
This option is required for fully standards-compliant handling of static
destructors, but will only work if your C library supports
__cxa_atexit.
The following options control the dialect of Fortran that the compiler accepts:
-ansi-auto-use module_name[,module_name]... openf95 -auto-use mpi_interface
or
openf95 -auto-use shmem_interface
Note in some situations using -auto-use can increase compiler time.
-byteswapio-colN-convert conversion-d-linesD in column 1 of compiled lines.
-default64-extend-source-noextend-source-nog77manglefoo in the source file becomes foo_ in the object file.
If the symbol name includes an underscore then the compiler will append a second
underscore to the symbol name in the object file, e.g., foo_ and foo_bar
in the source file becomes foo__ and foo_bar__ in the object file,
respectively. nog77mangle suppresses the appending of the second underscore.
-pad-char-literals-rreal_specKIND specification for real values.
-r4REAL(KIND=4) for real variables and COMPLEX(KIND=4) for complex
variables.
-r8REAL(KIND=8) for real variables and COMPLEX(KIND=8) for complex
variables.
-unameThe options described below can be used to control the features of the C/C++ or Fortran language.
-LANG:question=answer-LANG:copyinout=ON|OFF-LANG:formal_deref_unsafe=ON|OFF (Fortran Only)-LANG:global_asm=ON|OFF-LANG:heap_allocation_threshold=size-LANG:IEEE_minus_zero=ON|OFF (Fortran only)SIGN(3I),
suppressing the minus sign on zero. This deters problems created by optimizations
and hardware instructions that return a negative floating-point zero result from a
positive floating-point zero value.
Note use the -z option with the assign command to print the minus
sign of a negative floating-point zero.
The default is -LANG:IEEE_minus_zero=OFF.
-LANG:IEEE_save=ON|OFF (Fortran only)USE statement, then upon
entry the floating-point flags, halt mode, and rounding mode must be saved. When exiting the halt
and rounding mode must be restored and the saved floating-point flags must be logically OR
with the current floating-point flags. To improve runtime set the option to OFF.
The default is -LANG:IEEE_save=OFF.
-LANG:recursive=ON|OFF (Fortran only)When set to OFF the compiler can safely assume a statically allocated local variable will not be referenced or modified by a procedure call and can optimize more aggressively.
In either mode, the compiler supports a recursive stack-based calling sequence. The
difference is in the optimization of statically allocated local variables.
The default is -LANG:recursive=OFF.
-LANG:rw_const=ON|OFF (Fortran Only)-LANG:short_circuit_conditionals=ON|OFF (Fortran Only).AND. and .OR. by
applying a short-circuit methodology to the second operand.
Note if determined unnecessary, the compiler will not evaluate the second operand
even if problems occur in addition to the desired compilation effect.
The default is -LANG:short_circuit_conditionals=ON.
-alignN-align32-align64Objects smaller than the specified alignment (i.e. 32-bit or 64-bit) are aligned on boundaries according to the object size. For example if -align64 is selected:
-backslash-funwind-tables-fno-unwind-tables-finhibit-size-directive.size assembler directive, or anything else that
would cause trouble if the function is split in the middle, and the
two halves are placed at locations far apart in memory. This option is
used when compiling crtstuff.c; you should not need to use it
for anything else.
-fpicWhen this flag is set, the macros __pic__ and __PIC__
are defined to 1.
-fPICPosition-independent code requires special support, and therefore works only on certain machines.
When this flag is set, the macros __pic__ and __PIC__
are defined to 2.
-fno-ident#ident directive.
-HP:question=answer[,argument=N,...]-HUGEPAGE:question=answer[,argument=N,...]-HP-HUGEPAGEA mixed usage of huge pages and small pages is supported for heap allocation when huge page is not available. A mixed usage of huge pages and small pages for bss, data and text segments is not supported.
Currently, the compiler requires a modified version of the libhugetlbfs library functions,
see the release notes or supported versions.
Both a static link and dynamic link to the modified library functions are supported for huge
page heap allocation, but only dynamic link is supported for huge page” bdt” mapping.
-HP:bdt=size-HUGEPAGE:bdt=size-HP:heap=size[,argument=N,...]-HUGEPAGE:heap=size[,argument=N,...]Currently the huge page sub-option for the heap supports one argument,
-HUGEPAGE:heap=2m,limit=N, where the value N is used to
set the upper bound and represents a 32-bit integral number.
If the limit argument is not specify or N is set to a negative
number then no user-imposed limit is set and huge page usage is
only limited by the resources on the target machine.
For example, sub-options -HP:heap=2m and -HP:heap=2m,limit=-1
are equivalent and specify that the upper bound is limited by the target resources.
If the value of N is set to zero the huge page usages for heap is suppressed.
-HP-HUGEPAGE opencc -HP foo.c
is equivalent to
opencc -HP:heap=2m foo.c
Examples for using huge pages are:
opencc -HUGEPAGE:bdt=2m -HUGEPAGE:heap=2m,limit=850 -o foo foo.c
or in a condensed form
opencc -HP:bdt=2m:heap=2m,limit=850 -o foo foo.c
Note the huge page library, libhugetlbfs, is not NUMA sensitive.
It assumes that huge pages on all memory nodes in the system are available to all processes.
It is recommended to use the limit argument to impose an upper bound on the huge
page usage per process to avoid the situation that one process consumes all huge page
resources and starves the rest.
If ”numctrl -m” is used to bind a process to a specific memory node, then the
memory node must have enough huge pages to meet the demand.
Therefore it is required to configure sufficient huge pages for all threads and all processes.
Note the huge page library, libhugetlbfs, is not multithread safe.
-ignore-suffix-opencc-no-opencc-nobool-U nameThese options control various sorts of optimizations.
Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make any debugging session produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.
Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program.
The compiler performs optimization based on the knowledge it has of the program. Optimization levels -O and above, in particular, enable unit-at-a-time mode, which allows the compiler to consider information gained from later functions in the file when compiling a function. Compiling multiple files at once to a single output file in unit-at-a-time mode allows the compiler to use information gained from all of the files when compiling each of them.
Not all optimizations are controlled directly by a flag. Only optimizations that have a flag are listed.
Feedback directed optimizations (FDO) is used by the x86 Open64 compiler to improve performance. The program under development must be compiled at least twice. The first compilation generates an executable which contains extra instrumentation library calls required to gather feedback information. At runtime, this specified instrumented executable is used to gather the required profile information about the program. The profile data is then used in subsequent compilations to perform the necessary transformations to produce optimum code.
-fb-create filename opencc -O2 -ipa -fb-create fbdata -o foo foo.c
fbdata will contain the instrumented feedback data from the instrumented executable foo.
The default is -fb-create is disabled.
-fb-opt filename opencc -O2 -ipa -fb-opt fbdata -o foo foo.c
The new executable, foo, will be optimized to execute faster, and will not include any
instrumentation library calls.
Note the same optimization flags specified when creating the instrumented data file with the
-fb-create must be specified when invoking the compiler with the -fb-opt option.
Otherwise, the compiler will emit checksum errors.
The default is -fb-opt disabled.
-fb-phase=0|1|2|3|4-finstrument-functions__builtin_return_address does not work beyond the current
function, so the call site information may not be available to the
profiling functions otherwise.)
void __cyg_profile_func_enter (void *this_fn,
void *call_site);
void __cyg_profile_func_exit (void *this_fn,
void *call_site);
The first argument is the address of the start of the current function, which may be looked up exactly in the symbol table.
This instrumentation is also done for functions expanded inline in other functions. The profiling calls will indicate where, conceptually, the inline function is entered and exited. This means that addressable versions of such functions must be available. If all your uses of a function are expanded inline, this may mean an additional expansion of code size. If you use extern inline in your C code, an addressable version of such functions must be provided. (This is normally the case anyway, but if you get lucky and the optimizer always expands the functions inline, you might have gotten away without providing static copies.)
A function may be given the attribute no_instrument_function, in
which case this instrumentation will not be done. This can be used, for
example, for the profiling functions listed above, high-priority
interrupt routines, and any functions from which the profiling functions
cannot safely be called (perhaps signal handlers, if the profiling
routines generate output or allocate memory).
Note specifying -finstrument-functions implies -OPT:cyg_instr=3, for more details See -OPT:cyg_intsr=3.
-apo-O0|1|2|3|s-00-O1-O2-O3-OsIf you use multiple -O options, with or without level numbers,
the last such option is the one that is effective.
Level 2 is assumed if no value is specified (i.e. -O).
The default is -O2.
-Ofast -O3
-ipa
-OPT:Ofast
-fno-math-errno
-ffast-math
These optimization options are generally safe. Floating-point accuracy
may be affected due to the transformation of the computational code.
Note that the interprocedural analysis option, -ipa, specifies
limitations on how libraries and object files (.o files) are built.
-WOPT:question=answer-WOPT:aggstr=N-WOPT:const_pre=ON|OFF-WOPT:if_conv=0|1|2IF statements to
conditional move instructions. -WOPT:if_conv has three settings:
IF statement transformations. The context surrounding the IF
statement is used in the transformation decision.
IF statement transformations. Perform the IF statement transformation
regardless of the surrounding context.
The default is -WOPT:if_conv=1.
-WOPT:ivar_pre=ON|OFF-WOPT:mem_opnds=ON|OFF-WOPT:retype_expr=ON|OFF-WOPT:unroll=0|1|2IF
statements. Selecting this setting complements the loop unrolling performed in the code
generator.
IF statements. Selecting this
setting duplicates the unrolling performed in the code generator (i.e. unrolling
straight line code in the body of a loop).
Note -WOPT:unroll and the unrolling options in the -OPT group are
mutually exclusive.
The default is -WOPT:unroll=1.
-WOPT:val=0|1|2The options below control general optimizations that are not associated with a specific compilation phase.
The following options control specific optimizations. They are either activated by -O options or are related to ones that are. You can use the following flags in the rare cases when “fine-tuning” of optimizations to be performed is desired.
The following options control compiler behavior regarding floating point arithmetic. These options trade off between speed and precision. All must be specifically enabled.
-ffast-math-fno-fast-mathThis option causes the preprocessor macro __FAST_MATH__ to be defined.
Note:
-Ofast implies -ffast-math. -ffast-math sets options -fno-math-errno and -OPT:IEEE_arithmetic=2. -fno-fast-math sets options -fmath-errno and -OPT:IEEE arithmetic=1.
-ffloat-storeThis option prevents undesirable excess precision on the computations performed
in the floating-point unit, regardless of the original type (e.g., registers keep
more precision than a double is required to have).
For most programs, the excess precision does only good, but a few programs rely
on the precise definition of IEEE floating point.
Use -ffloat-store for such programs, after modifying
them to store all pertinent intermediate computations into variables.
-ffloat-store generates stores to memory of all pertinent immediate
computations to be truncated to a lower precision which may generate extra stores
slowing down program execution. (See -mx87-precision, for more details).
Note -ffloat-storehas no effect under -msse2, the default when specifying
-m32 and -m64.
-fno-math-errno-funsafe-math-optimizations-fno-unsafe-math-optimizations-mx87-precision=32|64|80-noexpopt-openmp-mp-OPT:question=answer-OPT:alias=model-OPT:align_unsafe=ON|OFFload and store
instructions.
Note the aligned memory accesses will execute faster than unaligned accesses, but
if the assumption is faulty the aligned memory accesses will result in runtime segmentation faults.
The default is -OPT:align_unsafe=OFF.
-OPT:asm_memory=ON|OFF-OPT:bb=N-OPT:cis=ON|OFFSIN/COS pairs that use identical arguments are converted to a single call and
both values are calculated at once.
The default is -OPT:cis=ON.
-OPT:cyg_instr=0|1|2|3|4void__cyg_profile_func_entry (void *func_address, void *return_address);
void__cyg_profile_func_exit (void *func_address, void *return_address);
Where, the first argument is the address at the start of the current function and the second argument is the return address into the caller of the current function.
-OPT:cyg_instr has five settings that control which functions are not instrumented:
inline in the source.
extern inline or always_inline.
extern inline functions.
Specifing this value may create linking and runtime faults.
For any function assigned the attribute no_instrument_function,
instrumentation will be suppressed (e.g., do not instrument functions
__cyg_profile_func_enter and __cyg_profile_func_exit).
-OPT:div_split=ON|OFFx/y into x*(recip(y)).
Flags -OPT:Ofast or -OPT:IEEE_arithmetic=3 will
enable this option.
Note this transformation generates fairly accurate code.
The default is -OPT:div_split=OFF.
-OPT:early_mp=ON|OFFThe default is -OPT:early_mp=OFF.
-OPT:early_intrinsics=ON|OFF-OPT:fast_bit_intrinsics=ON|OFF (Fortran Only)BTEST or ISHFT)
will be turned off.
The default is -OPT:fast_bit_intrinsics=OFF.
-OPT:fast_complex=ON|OFFcomplex.
Fast algorithms are used for complex absolute value and complex division. The algorithm
will overflow for an operand (e.g., the divisor in the case of division) that
has an absolute value that is larger than the square root of the largest representable
floating-point number. Also, the algorithm will underflow for a value that is
smaller than the square root of the smallest representable floating point number.
Note, specifying -OPT:roundoff=3 will also set -OPT:fast_complex=ON.
The default is -OPT:fast_complex=OFF.
-OPT:fast_exp=ON|OFF-OPT:fast_io=ON|OFF (C/C++ Only)printf(), fprintf(),
sprintf(), scanf(), fscanf(), sscanf(), and printw()
for more specialized lower-level subroutines. The option invokes inlining only if the prospects
are marked as intrinsic in the respective header files
(i.e. <stdio.h> and <curses.h>)
Note programs that use I/O functions (e.g., printf() or scanf()
extensively generally have improved I/O performance when this flag is enabled.
Use of this option may create substantial code expansion.
The default is -OPT:fast_io=OFF.
-OPT:fast_math=ON|OFF-OPT:fast_nint=ON|OFFNINT and ANINT. Note if -OPT:roundoff=3 is specified then -OPT:fast_nint=ON.
The default is -OPT:fast_nint=OFF.
-OPT:fast_sqrt=ON|OFFsqrt(x)= x*rsqrt(x) (where rsqrt equals the reciprocal square root operation).
Fairly accurate code is generated when specifying this transformation.
Note -OPT:fast_exp=ON must be specified which instructs the compiler to generate
inlined instructions and not to call the library pow function before -OPT:fast_sqrt=ON can
perform its transformation. -OPT:fast_sqrt has no dependencies on -OPT:rsqrt and unlike
-OPT:rsqrt the transformation request by -OPT:fast_sqrt does not generate extra
instructions when implementing rsqrt.
The default is -OPT:fast_sqrt=OFF.
-OPT:fast_stdlib=ON|OFF-OPT:fast_trunc=ON|OFFNINT, ANINT, and AMOD.
Note -OPT:fast_trunc=ON is specified if -OPT:roundoff is equal to or greater than 1.
The default is -OPT:fast_trunc=OFF.
-OPT:fold_reassociate=ON|OFF-OPT:fold_unsafe_relops=ON|OFFNote, specifying -O3 sets -OPT:fold_unsafe_relops=ON.
The default is -OPT:fold_unsafe_relops=OFF.
-OPT:fold_unsigned_relops=ON|OFF-OPT:goto=ON|OFFGOTO into higher level structures e.g., FOR loops.
Note if -O2 is specified then -OPT:goto=ON.
The default is -OPT:goto=OFF.
-OPT:IEEE_arithmetic=1|2|3-OPT:IEEE_arith=1|2|3-OPT:IEEE_a=1|2|3-OPT:IEEE_NaN_inf=ON|OFFWhen setting this option to OFF, various operations that do not
produce IEEE-754 results.
For example, x/x is set to the value 1 without performing a divide operation and
x=x is set to TRUE without executing a test operation.
-OPT:IEEE_NaN_inf=OFF also specifies multiple optimizations that increase performance.
The default is -OPT:IEEE_NaN_inf=OFF.
-OPT:inline_intrinsics=ON|OFF (Fortran Only)-OPT:keep_ext=ON|OFF-OPT:malloc_algorithm=0|1-OPT:malloc_alg=0|1main function.
The default is -OPT:malloc_algorithm=0
-OPT:Ofast-OPT:Olimit=N-OPT:pad_common=ON|OFFEQUIVALENCE) are consistent among all source codes
making up a program.
DATA statements
-OPT:recip=ON|OFF1.0/y
This may change the accuracy of the results.
For example, X = 1./Y generates the reciprocal instruction instead of a
divide instruction.
The default is -OPT:recip=OFF.
-OPT:reorg_common=ON|OFF-OPT:reorg_common=ON_OPT:reorg_common=OFF-OPT:roundoff=0|1|2|3-OPT:ro=0|1|2|3This is the default when specifying -OPT:Ofast
-OPT:rsqrt=0|1|2-OPT:space=ON|OFF-OPT:speculate=ON|OFF-OPT:transform_to_memlib=ON|OFFmemcpy or memset.
The default is -OPT:transform_to_memlib=ON.
-OPT:treeheight=ON|OFF-OPT:unroll_analysis=ON|OFF-OPT:unroll_level=1|2-OPT:unroll_times_max=N-OPT:unroll_size=N-OPT:wrap_around_unsafe_opt=ON|OFFInline expansion, or inlining, is a compiler optimization that replaces a function call with the body of the function. This optimization may improve time and space usage at runtime, at the possible cost of increasing the final code size.
-fimplicit-inline-templates (C++ Only)-fno-implicit-inline-templates (C++ Only)-fimplicit-templates (C++ Only)-fno-implicit-templates (C++ Only)-finline-fno-inline-inline-INLINE-noinlineinline keyword.
Note when performing interprocedural analysis (IPA) then -IPA:inline=OFF
must be specified when disabling inlining.
-finline-functions (C/C++ Only)-fno-inline-functions (C/C++ Only)static, then normally assembler code is not generated for the function.
Specifying -fno-inline-functions will disable the automatic integration
of simple functions.
Note this option is enabled at optimization level 3, -O3.
The default is -fno-inline-function.
-fkeep-inline-functions (C/C++ Only)static functions that are declared inline
into the object file, even if the function has been inlined into all
of its callers.
This switch does not affect functions using the
extern inline extension in C. In C++, emit any and all
inline functions into the object file.
-INLINE:question=answer-INLINE:all-INLINE:aggressive=ON|OFF-INLINE:list=ON|OFF-INLINE:must=name1[,name2,...]-INLINE:never=name1[,name2,...]-INLINE:none-INLINE:preempt=ON|OFF-ipa-IPA-IPA:-IPA:question=answer-IPA:addressing=ON|OFF-IPA:aggr_cprop=ON|OFF-IPA:alias=ON|OFFALIAS, MOD, and REF analysis.
-IPA:alias=ON specifies an interprocedural analysis that provides results not affected by
control flow in procedures.
The default is -IPA:alias=ON.
-IPA:callee_limit=N-IPA:cgi=ON|OFF-IPA:clone_list=ON|OFF-IPA:common_pad_size=N-IPA:cprop=ON|OFF-IPA:ctype=ON|OFF<ctype.h>
header macros (e.g., isalpha(), isascii(),...).
Note using this option when compiling multithreaded code and in all locales
(i.e. other than the 7-bit ASCII or C-language locale) may generate unstable executables.
The default is -IPA:ctype=OFF
-IPA:depth=N-IPA:dfe=ON|OFF-IPA:dve=ON|OFF-IPA:echo=ON|OFF-IPA:field_reorder=ON|OFF-IPA:forcedepth=N-IPA:ignore_lang=ON|OFF-IPA:inline=ON|OFF-IPA:keeplight=ON|OFF-IPA:linear=ON|OFF-IPA:map_limit=N-IPA:maxdepth=N-IPA:max_jobs=NThe default is -IPA:max_jobs=1.
-IPA:min_hotness=N-IPA:multi_clone=N-IPA:node_bloat=N-IPA:plimit=N-IPA:pu_reorder=0|1|2-IPA:relopt=ON|OFF-IPA:small_pu=N-IPA:sp_partition=ON|OFF-IPA:space=N-IPA:specfile=filename-IPA:use_intrinsic=ON|OFFmalloc library function. This option improves small object
allocations.
The default is -IPA:use_intrinsic=OFF.
-LNO:question=answerTo verify the LNO options that were invoked during compilation use the option -LIST:all_options=ON.
-LNO:apo_use_feedback=ON|OFF-LNO:build_scalar_reductions=ON|OFF-LNO:blocking=ON|OFF-LNO:blocking_size=N-LNO:fission=0|1|2Note loop fusion is usually applied before loop fission,
therefore if -LNO:fission=ON and -LNO:fusion=ON when the
compiler is invoked a reverse effect may be induced. To counter this effect
specify -LNO:fission=2 to instruct the compiler to perform loop
fission prior to loop fusion.
The default is -LNO:fission=0.
-LNO:full_unroll=N-LNO:fu=N-LNO:full_unroll_size=N-LNO:full_unroll_outer=ON|OFF-LNO:fusion=0|1|2The default is -LNO:fusion=1.
-LNO:fusion_peeling_limit=N-LNO:gather_scatter=0|1|2IF statements.
The default is -LNO:gather_scatter=1.
-LNO:hoistif=ON|OFFIF statements which
reside inside inner loops. This optimization will eliminate
redundant loops.
The default is -LNO:hoistif=ON.
-LNO:ignore_feedback=ON|OFF-LNO:ignore_pragmas=ON|OFF-LNO:local_pad_size=N-LNO:minvariant=ON|OFF-LNO:minvar=ON|OFF-LNO:non_blocking_loads=ON|OFF (C/C++ Only)-LNO:oinvar=ON|OFF-LNO:opt=0|1The default is -LNO:opt=1
-LNO:ou_prod_max=N-LNO:outer=ON|OFF-LNO:outer_unroll_max=N-LNO:ou_max=N-LNO:parallel_overhead=N-LNO:prefetch=0|1|2|3The default is -LNO:prefetch=2.
-LNO:prefetch_ahead=N-LNO:prefetch_verbose=ON|OFF-LNO:processors=N-LNO:sclrze=ON|OFF-LNO:simd=0|1|2The default is LNO:simd=1.
-LNO:simd_reduction=ON|OFF-LNO:simd_verbose=ON|OFF-LNO:svr_phase1=ON|OFF-LNO:trip_count_assumed_when_unknown=N-LNO:trip_count=N-LNO:vintr=0|1|2The default is -LNO:vintr=1.
-LNO:vintr_verbose=ON|OFFThe following Loop Transformation Suboptions allow the user to control cache blocking, loop unrolling, and loop interchange.
-LNO:interchange=ON|OFF-LNO:unswitch=ON|OFF-LNO:unswitch_verbose=ON|OFF-LNO:outer_unroll=N-LNO:ou=N-LNO:outer_unroll_deep=ON|OFF-LNO:ou_deep=ON|OFF-LNO:outer_unroll_further=N-LNO:ou_further=NOption -LNO:ou_further is the abbreviated form.
The default is ou_further=6.
-LNO:outer_unroll_max=N-LNO:ou_max=N-LNO:pwr2=ON|OFF (C/C++ Only)The following LNO Target Cache Memory Suboptions allows the user to specify the target cache/memory system. The suboption arguments are numbered starting with the cache closest to the processor and progresses outward.
-LNO:assoc1=N, assoc2=N, assoc3=N, assoc4=N-LNO:cmpl=N, cmp2=N, cmp3=N, cmp4=N, dmp1=N, dmp2=N, dmp3=N, dmp4=N-LNO:cs1=N. cs2=N, cs3=N, cs4=NNote:
Invoking the compiler with -LIST:all_options=ON will emit the
default cache sizes of the host system being used for compilation.
Cache sizes for each level of cache and memory are system dependent.
The default is N=0 for each level of cache.
-LNO:is_mem1=ON|OFF, is_mem2=ON|OFF, is_mem3=ON|OFF, is_mem4=ON|OFFAn attempt to perform loop blocking is permitted once the memory model has been structured. Note specify loop blocking suitable for memory and not for cache. No prefetching is performed and all prefetching options are disregarded.
Note LNO suboption -LNO:is_memx=ON|OFF supersedes
the corresponding suboptions -LNO:assocx=N and
-LNO:cmpx=N,...., dmpx=N.
-LNO:ls1=N, ls2=N, ls3=N, ls4=NThe following LNO Translation Lookaside Buffer Suboptions allows the user to specify the translation lookaside buffer (TLB) chacteristics. The suboption arguments are specified under the assumption that the cache for the page table is fully associative.
-LNO:ps1=N, ps2=N, ps3=N, ps4=N-LNO:tlb1=N, tlb2=N, tlb3=N, tlb4=N-LNO:tlbcmp1=N, tlbcmp2=N, tlbcmp3=N, tlbcmp4=N, tlbdmp1=N, tlbdmp2=N, tlbdmp3=N, tlbdmp4=NThe following LNO Prefetch Suboptions allows the user to specify prefetch operations.
-LNO:assume_unknown_trip_count=N-LNO:pf1=ON|OFF, pf2=ON|OFF, pf3=ON|OFF, pf4=ON|OFF-LNO:prefetch=0|1|2|3The defaulti is -LNO:prefetch=2
-LNO:prefetch_ahead=N-LNO:prefetch_manual=ON|OFFThese options control the C preprocessor, which is run on each C source file before actual compilation.
If you specify the -E option nothing is done except preprocessing. See option -E, in Option Controlling the Kind of Output section. Some of these options make sense only together with -E because they cause the preprocessor output to be unsuitable for actual compilation.
-A predicate=answer-A -predicate=answer-C (C Only)The user will note the following side effects when using -C; it
causes the preprocessor to treat comments as tokens in their own right.
For example, comments appearing at the start of what would be a
directive line have the effect of turning that line into an ordinary
source line, since the first token on the line is no longer a #.
-cppNote options -ftpp, -E, and -nocpp provide additional control of preprocessing. The -macro-expand option can be specified to enable macro expansion.
The default is the pass input files with suffix .F or .F90 through the
C preprocessor (i.e. cpp). Preprocessing is not performed on files that have suffixes
.f or .f90.
-dCHAR#include directives in addition to preprocessor results.
-Dname1.
The name must be declared as a logical constant in
the source files and will be set to true.
-Dname=definition-Dvar=definition[,var=definition,...]Note if the definition (i.e. def) is not specified a 1 is used. See -Uname, for information on undefined variables. -D and -U options are processed in the order they are given on the command line.
If you are invoking the preprocessor from a shell or shell-like program you may need to use the shell's quoting syntax to protect characters such as spaces that have a meaning in the shell syntax.
If you wish to define a function-like macro on the command line, write
its argument list with surrounding parentheses before the equals sign
(if any). Parentheses are meaningful to most shells, so you will need
to quote the option. For example, with sh and csh,
-D'name(args...)=definition'.
-fcoco=filename (Fortran Only)–I flags are passed to the preprocessor and take precedence over the setfile.
–D flags are passed to the preprocessor to assign values to constants and take
precedence over values assigned within the source files. If the option is of the form
-Dname=definition, the definition
on the right side must be an integer, and the name on the left side must be declared
as an integer constant within the source files. Otherwise, the name must be declared
as a logical constant within the source files, and will be set true. Constants defined
by -D should not be defined in the filename.
-fe-fpreprocessed (C/C++ Only)-fno-preprocessed (C/C++ Only)-ftpp (Fortran Only)By default, only files with suffix .F, .F90, or .F95
are processed by the C source preprocessor, cpp.
Source files with suffix .f, .f90, or .f95 are
not processed by the preprocessor
-MUnless specified explicitly (with -MT or -MQ), the object file name consists of the basename of the source file with any suffix replaced with object file suffix. If there are many included files then the rule is split into several lines using \-newline. The rule has no commands.
To avoid mixing such debug output with the dependency rules you should explicitly specify the dependency output file with -MF, or use an environment variable like DEPENDENCIES_OUTPUT. Debug output will still be sent to the regular output stream as normal.
Passing -M to the driver implies -E, and suppresses
warnings with an implicit -w.
-macro-expand (Fortran Only)# directives only.
-MDIf -MD is used in conjunction with -E, any -o switch is understood to specify the dependency output file (see -MF), but if used without -E, each -o is understood to specify a target object file.
Since -E is not implied, -MD can be used to generate
a dependency output file as a side-effect of the compilation process.
-MDtarget filename (Fortran Only)-MDupdate filename (Fortran and C Only)-MF filenameWhen used with the driver options -MD or -MMD,
-MF overrides the default dependency output file.
-MG#include directive without prepending any path. -MG
also suppresses preprocessed output, as a missing header file renders
this useless.
This feature is used in automatic updating of makefiles.
-MMThis implies that the choice of angle brackets or double quotes in an
#include directive does not in itself determine whether that
header will appear in -MM dependency output. This is a
slight change in semantics from GCC versions 3.0 and earlier.
-MMD-MPThis is typical output:
test.o: test.c test.h
test.h:
-MQ target (C/C++ Only) $$(objpfx)foo.o: foo.c
The default target is automatically quoted, as if it were given with
-MQ.
-MT target (C/C++ Only)An -MT option will set the target to be exactly the string you specify. If you want multiple targets, you can specify them as a single argument to -MT, or use multiple -MT options.
For example, -MT '$(objpfx)foo.o' might give
$(objpfx)foo.o: foo.c
-nocpp (Fortran Only)-no-gcc (Fortran Only)__GNUC__
-P-Uname-Wp,option,...You can pass options to the assembler.
-fno-asm (C/C++ Only)asm, inline or typeof as a
keyword, so that code can use these words as identifiers. You can use
the keywords __asm__, __inline__ and __typeof__
instead. -ansi implies -fno-asm.
In C++, this switch only affects the typeof keyword, since
asm and inline are standard keywords. You may want to
use the -fno-gnu-keywords flag instead, which has the same
effect. In C99 mode (-std=c99 or -std=gnu99), this
switch only affects the asm and typeof keywords, since
inline is a standard keyword in ISO C99.
-Wa,option,...These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step.
-arNote options specified with the -WR,option-list must include all objects that will be incorporated in the archive, otherwise prelinked internal errors will be emitted. In the following example:
openCC -ar -WR,-v -o liba.a file1.o file2.o file3.o
liba.a is an archive which incorporates files file1.o, file2.o,
and file3.o. Object files file1.o, file2.o,
and file3.o are prelinked to instantiate all required template entities.
Then the ar -r -c -v liba.a file1.o file2.o file3.o command is invoked.
Even if only file3.o needs to be replaced in liba.a, all three object
files must be specified.
-c-S-E-ffast-stdlib-fno-fast-stdlib-H-l libraryIt makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, foo.o -lz bar.o searches library z after file foo.o but before bar.o. If bar.o refers to functions in z, those functions may not be loaded.
The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.
The directories searched include several standard system directories plus any that you specify with -L.
Normally the files found this way are library files—archive files
whose members are object files. The linker handles an archive file by
scanning through it for members which define symbols that have so far
been referenced but not defined. But if the file that is found is an
ordinary object file, it is linked in the usual fashion. The only
difference between using an -l option and specifying a file name
is that -l surrounds library with lib and .a
and searches several directories.
-nostartfiles-nodefaultlibsmemcmp,
memset, memcpy and memmove.
These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
-nostdinc#include files and files named in the INCLUDE
statements.
-nostdinc++ (C++ Only)-nostdlibmemcmp, memset,
memcpy and memmove.
These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
One of the standard libraries bypassed by -nostdlib and
-nodefaultlibs is libgcc.a, a library of internal subroutines
that the compiler uses to overcome shortcomings of particular machines, or special
needs for some languages.
In most cases, you need libgcc.a even when you want to avoid
other standard libraries. In other words, when you specify -nostdlib
or -nodefaultlibs you should usually specify -lgcc as well.
This ensures that you have no unresolved references to internal GCC
library subroutines.
-objectlist filename-shared-shared-libgcc-static-libgccThere are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.
Therefore, the openCC drivers automatically add -shared-libgcc whenever you build a shared library or a main executable, because C++ programs typically use exceptions, so this is the right thing to do.
If, instead, you use the opencc driver to create shared libraries, you may find that they will not always be linked with the shared libgcc. If the compiler finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it will link the shared version of libgcc into shared libraries by default. Otherwise, it will take advantage of the linker and optimize away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries, without incurring relocation costs at library load time.
However, if a library or main executable is supposed to throw or catch
exceptions, you must link it using the openCCdriver or using the option
-shared-libgcc, such that it is linked with the shared
libgcc.
-static--static-static-data (Fortran Only)The -static-data cannot be specified when compiling an external routine that is called by a program which contains parallel loops targeting a multiprocessor system. Static and multiprocessor compiled object files can be mixed in the same executable, but a static routine cannot be called from within a parallel region.
Note option -static-data is useful when porting programs from legacy systems in which
all variables are allocated as static.
-stdinc-symbolic-Xlinker optionIf you want to pass an option that takes an argument, you must use
-Xlinker twice, once for the option and once for the argument.
For example, to pass -assert definitions, you must write
-Xlinker -assert -Xlinker definitions. It does not work to write
-Xlinker "-assert definitions", because this passes the entire
string as a single argument, which is not what the linker expects.
-Wl,option,...These machine-independent options control the interface conventions used in code generation.
-CG:question=answer-CG:cflow=ON|OFF-CG:cmp_peep=ON|OFF-CG:compute_to=on|off-CG:cse_regs=N-CG:gcm=ON|OFF-CG:inflate_reg_request=N-CG:load_exe=N-CG:local_sched_alg=0|1|2-CG:locs_best=ON|OFF-CG:locs_reduce_prefetch=ON|OFF-CG:locs_shallow_depth=ON|OFF-CG:movnti=N-CG:p2align=ON|OFF-CG:p2align_freq=N-CG:post_local_sched=ON|OFF-CG:pre_local_sched=ON|OFF-CG:prefer_legacy_regs=ON|OFFrex byte.
The default is -CG:prefer_legacy_regs=OFF.
-CG:prefetch=ON|OFF-CG:ptr_load_use=N-CG:push_pop_int_saved_regs=ON|OFF-CG:sse_cse_regs=N-CG:unroll_fb_req=ON|OFF-CG:use_prefetchnta=ON|OFF-CG:use_test=ON|OFFTEST instruction instead of the CMP
instruction.
The default is -CG:use_test=OFF.
-GRA:question=answer-GRA:home=ON|OFF-GRA:optimize_boundary=ON|OFF-GRA:prioritize_by_density=ON|OFF-GRA:unspill=ON|OFFx86 Open64 provides options that will switch to another cross-compiler or target environment. The target environment is the system upon which the executable code will be run.
-TENV:question=answer-TENV:frame_pointer=ON|OFF-TENV:simd_dmask=ON|OFF-TENV:simd_imask=ON|OFF-TENV:simd_omask=ON|OFF-TENV:simd_pmask=ON|OFF-TENV:simd_umask=ON|OFF-TENV:simd_zmask=ON|OFF-TENV:X=0,1,2,3,4Earlier we discussed the option -TENV: which chooses among different environments for completely different target machines.
In addition, each of these target machine types can have its own special options, starting with -m, to choose among various hardware models or configurations—for example, 80386 vs AMD Opteron, floating coprocessor or none. A single installed version of the compiler can compile for any model or configuration, according to the options specified.
Some configurations of the compiler also support additional special options, usually for compatibility with other compilers on the same platform.
These -m options are defined for the i386 and x86-64 family of computers in 32-bit and 64-bit environments:
-march=cpu-type-mtune=cpu-type-mcpu=cpu-typeTune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are:
As new processors are deployed in the marketplace, the behavior of this
option will change. Therefore, if you upgrade to a newer version of
x86 Open64, the code generated option will change to reflect the processors
that were most common when that version of Open64 was released.
While picking a specific cpu-type will schedule things appropriately
for that particular chip, the compiler will not generate any code that
does not run on the i386 without the -march=cpu-type option
being used.
-msse-mno-sse-msse2-mno-sse2-msse3-mno-sse3-msse4a-mno-msse4a-m3dnow-mno-3dnowThese options will enable the compiler to use these extended instructions in generated code.
-msse-mno-msse-msse2-mno-msse2-msse-mno-msse3-msse4a-mno-msse4a-m3dnow-mno-m3dnowNote applications which perform runtime CPU detection must compile
separate files for each supported architecture, using the appropriate flags.
In particular, the file containing the CPU detection code should be compiled without
these options.
-m32-m64-mcmodel=small|mediumTraditionally, diagnostic messages have been formatted irrespective of the output device's aspect (e.g. its width, ...). The options described below can be used to control the diagnostic messages formatting algorithm, e.g. how many characters per line, how often source location information should be reported, etc. Right now, only the C++ front end can honor these options. However it is expected, in the near future, that the remaining front ends would be able to digest them correctly.
-C (Fortran only)-clist (C Only)-CLIST:=answer (C Only)-CLIST:question=answer (C Only)Option -clist is equivalent to -CLIST:=ON. Specifing any variation of option -CLIST:question=answer implies -clist, (i.e. with the exception of –CLIST:=OFF). The individual controls in this group are as follows:
-clist-CLIST:=ON|OFF-CLIST:dotc_file=filename-CLIST:doth_file=filename-CLIST:emit_pfetch=ON|OFF-CLIST:linelength=N-CLIST:show=ON|OFF-ffortran-bounds-check (Fortran Only)-flist (Fortran Only)-FLIST:=answer (Fortran Only)-FLIST:question=answer (Fortran Only)Option -flist is equivalent to -FLIST:=ON. Specifing any variation of option -FLIST:question=answer implies -flist, (i.e. with the exception of –FLIST:=OFF). The individual controls in this group are as follows:
-flist-FLIST:=ON|OFF-FLIST:ansi_format=ON|OFF-FLIST:emit_pfetch=ON|OFFThe written comments appear after a read/write to a variable and note the
identifier of the prefetch-spec for each level of the cache.
The default is -FLIST:emit_pfetch=OFF.
-FLIST:ftn_file=filename-FLIST:linelength=N-FLIST:show=ON|OFF-fpermissive-fno-permissiveUsing the -fpermissive flag will also let the compiler accept
the code, by marking all function calls for which no declaration is visible
at the time of definition of the template for later lookup at instantiation
time, as if it were a dependent call. We do not recommend using ‘-fpermissive’
to work around invalid code, and it will also only catch cases where functions
in base classes are called, not where variables in base classes are used.
-fullwarn-pedantic-errors (C Only)Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few will require -ansi or a -std option specifying the required version of ISO C). However, without this option, certain GNU extensions and traditional C and C++ features are supported as well. With this option, they are rejected.
-pedantic-errors does not cause error messages for use of the
alternate keywords whose names begin and end with __. Pedantic
errors are also disabled in the expression that follows
__extension__. However, only system header files should use
these escape routes; application programs should avoid them.
Some users try to use -pedantic-errors to check programs for strict ISO C conformance. They soon find that it does not do quite what they want: it finds some non-ISO practices, but not all—only those for which ISO C requires a diagnostic, and some others for which diagnostics have been added.
Where the standard specified with -std represents a GNU
extended dialect of C, such as gnu89 or gnu99, there is a
corresponding base standard, the version of ISO C on which the GNU
extended dialect is based. Errors from -pedantic-errors are given
where they are required by the base standard.
-subverbose-trapuv-zerouvx86 Open64 has various special options that are used for evaluating and debugging your program:
-dletters-dD-dI#include directives in addition to preprocessor results.
-dM-dN-fprofile-arcs-frandom-seed=string (C/C++ Only)The string can be any character string and should be different
for every file you compile.
-ftest-coverage-g-glevelOpen64 allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move to where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
-g0-g1-g2-g3-gdwarf-2-gdwarf-20-gdwarf-21-gdwarf-22-gdwarf-23-p-pg-profileWarnings are diagnostic messages that report constructions which are not inherently erroneous but which are risky or suggest there may have been an error.
You can request many specific warnings with options beginning -W, for example -Wimplicit to request warnings on implicit declarations. Some of these specific warning options also has a negative form beginning -Wno- to turn off warnings; for example, -Wno-implicit.
Most of these options have both positive and negative forms; the negative form of -Wfoo would be -Wno-foo. This manual typically defines only one of these two forms, whichever one is not the default.
The following options control the amount and kinds of warnings produced by the x86 Open64 compiler for the C/C++ and Fortran Dialects; for further, language-specific options also refer to C Dialect Options and Fortran Dialect Options.
-w-Wall-Wbad-function-castint malloc() is cast to anything *.
-Wdeprecated-Wno-deprecated-Wdisabled-optimization-Wno-disabled-optimization-Wdiv-by-zero-Wno-div-by-zero-Wendif-labels-Wno-endif-labels-Werror-Wno-errorMake the specified warning into an error. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. You can use the -fdiagnostics-show-option option to have each controllable warning amended with the option which controls it, to determine what to use with this option.
Note that specifying -Werror=foo automatically implies
-Wfoo. However, -Wno-error=foo does not
imply anything.
-Wfloat-equal-Wno-float-equal-Wimport-Wno-import-Wlarger-than-len-Wno-larger-than-len-Wno-deprecated-declarationsdeprecated
attribute.
-woff-woffall-woffoptions-woffnumFor example:
opencc -woff2056 -o foo foo.c
Instructs the compiler to suppress warning message number 2056.
opencc -woff2056-2300 -o foo foo.c
Instructs the compiler to suppress warning message numbers 2056 thru 2300.
opencc -woff2056-2300,2420-2500 -o foo foo.c
Instructs the compiler to suppress warning message number 2056 thru 2300 and
2420 thru 2500.
-Wundef-Wno-undef-Wuninitialized-Wno-uninitializedsetjmp call.
These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when optimizing. If you do not specify -O, you will not get these warnings. Instead, the compiler will issue a warning about -Wuninitialized requiring -O.
If you want to warn about code which uses the uninitialized value of the variable in its own initializer, use the -Winit-self option.
These warnings occur for individual uninitialized or clobbered
elements of structure, union or array variables as well as for
variables which are uninitialized or clobbered as a whole. They do
not occur for variables or elements declared volatile. Because
these warnings depend on optimization, the exact variables or elements
for which there are warnings will depend on the precise optimization
options.
Note that there may be no warning about a variable that is used only to compute a value that itself is never used, because such computations may be deleted by data flow analysis before the warnings are printed.
These warnings are made optional because the compiler is not smart enough to see all the reasons why the code might be correct despite appearing to have an error. Here is one example of how this can happen:
{
int x;
switch (y)
{
case 1: x = 1;
break;
case 2: x = 4;
break;
case 3: x = 5;
}
foo (x);
}
If the value of y is always 1, 2 or 3, then x is
always initialized, but the compiler doesn't know this. Here is
another common case:
{
int save_y;
if (change_y) save_y = y, y = new_y;
...
if (change_y) y = save_y;
}
This has no bug because save_y is used only if it is set.
This option also warns when a non-volatile automatic variable might be
changed by a call to longjmp. These warnings as well are possible
only in optimizing compilation.
The compiler sees only the calls to setjmp. It cannot know
where longjmp will be called; in fact, a signal handler could
call it at any point in the code. As a result, you may get a warning
even when there is in fact no problem because longjmp cannot
in fact be called at the place which would cause a problem.
Some spurious warnings can be avoided if you declare all the functions
you use that never return as noreturn.
This warning is enabled by -Wall.
-Wunknown-pragmas-Wno-unknown-pragmas-Wunreachable-code-Wno-unreachable-codeThis option is intended to warn when the compiler detects that at least a whole line of source code will never be executed, because some condition is never satisfied or because it is after a procedure that never returns.
It is possible for this option to produce a warning even though there are circumstances under which part of the affected line can be executed, so care should be taken when removing apparently-unreachable code.
For instance, when a function is inlined, a warning may mean that the line is unreachable in only one inlined copy of the function.
This option is not made part of -Wall because in a debugging
version of a program there is often substantial code which checks
correct functioning of the program and is, hopefully, unreachable
because the program does work. Another common use of unreachable
code is to provide behavior which is selectable at compile-time.
-Wunused-Wno-unused-Wunused-function-Wno-unused-function-Wunused-label-Wno-unused-label-Wunused-parameter-Wno-unused-parameter-Wunused-value-Wno-unused-value-Wunused-variable-Wno-unused-variable-Wwrite-strings-Wno-write-stringsconst
char[length] so that
copying the address of one into a non-const char *
pointer will get a warning; when compiling C++, warn about the
deprecated conversion from string literals to char *. This
warning, by default, is enabled for C++ programs.
These warnings will help you find at
compile time code that can try to write into a string constant, but
only if you have been very careful about using const in
declarations and prototypes. Otherwise, it will just be a nuisance;
this is why we did not make -Wall request these warnings.
The following options control the amount and kinds of warnings produced by the compiler for the C/C++ dialect only; for further, language-specific options also refer to C Dialect Options.
-Waggregate-return-Wcast-align-Wno-cast-alignchar * is cast to
an int * on machines where integers can only be accessed at
two- or four-byte boundaries.
-Wchar-subscripts-Wno-char-subscriptschar. This is a common cause
of error, as programmers often forget that this type is signed on some
machines.
This warning is enabled by -Wall.
-Wcomment-Wno-comment-Wconversion-Wno-conversionAlso, warn if a negative integer constant expression is implicitly
converted to an unsigned type. For example, warn about the assignment
x = -1 if x is unsigned. But do not warn about explicit
casts like (unsigned) -1.
-Wdeclaration-after-statement-Wformat-Wno-formatprintf and scanf, etc., to make sure that
the arguments supplied have types appropriate to the format string
specified, and that the conversions specified in the format string make
sense. This includes standard functions, and others specified by format
attributes
, in the printf,
scanf, strftime and strfmon (an X/Open extension,
not in the C standard) families (or other target-specific families).
Which functions are checked without format attributes having been
specified depends on the standard version selected, and such checks of
functions without the attribute specified are disabled by
-ffreestanding or -fno-builtin.
The formats are checked against the format features supported by GNU
libc version 2.2. These include all ISO C90 and C99 features, as well
as features from the Single Unix Specification and some BSD and GNU
extensions. Other library implementations may not support all these
features; The compiler does not support warning about features that go beyond a
particular library's limitations. However, if -pedantic is used
with -Wformat, warnings will be given about format features not
in the selected standard version (but not for strfmon formats,
since those are not in any version of the C standard). See Options Controlling C Dialect.
Since -Wformat also checks for null format arguments for several functions, -Wformat also implies -Wnonnull.
-Wformat is included in -Wall. For more control over some
aspects of format checking, the options -Wformat-y2k,
-Wno-format-extra-args, -Wno-format-zero-length,
-Wformat-nonliteral, -Wformat-security, and
-Wformat=2 are available, but are not included in -Wall.
-Wformat-nonliteral-Wno-format-nonliteralva_list.
-Wformat-security-Wno-format-securityprintf and scanf functions where the
format string is not a string literal and there are no format arguments,
as in printf (foo);. This may be a security hole if the format
string came from untrusted input and contains %n. (This is
currently a subset of what -Wformat-nonliteral warns about, but
in future warnings may be added to -Wformat-security that are not
included in -Wformat-nonliteral.)
-wid-clash-wno-id-clashnum characters.
-Wimplicit-Wno-implicit-Wimplicit-function-declaration-Wno-implicit-function-declaration-Wimplicit-int-Wno-implicit-int-Winline-Wno-inlineThe compiler uses a variety of heuristics to determine whether or not
to inline a function. For example, the compiler takes into account
the size of the function being inlined and the amount of inlining
that has already been done in the current function. Therefore,
seemingly insignificant changes in the source program can cause the
warnings produced by -Winline to appear or disappear.
-Wmain-Wno-main-Wmissing-braces-Wno-missing-braces int a[2][2] = { 0, 1, 2, 3 };
int b[2][2] = { { 0, 1 }, { 2, 3 } };
This warning is enabled by -Wall.
-Wmissing-declarations-Wno-missing-declarations-Wmissing-format-attribute-Wno-missing-format-attributeformat
attributes. Note these are only possible candidates, not absolute ones.
The compiler will guess that function pointers with format attributes that
are used in assignment, initialization, parameter passing or return
statements should have a corresponding format attribute in the
resulting type. That is: the left-hand side of the assignment or
initialization, the type of the parameter variable, or the return type
of the containing function respectively should also have a format
attribute to avoid the warning.
The compiler will also warn about function definitions which might be
candidates for format attributes. Again, these are only
possible candidates. The compiler will guess that format attributes
might be appropriate for any function that calls a function like
vprintf or vscanf, but this might not always be the
case, and some functions for which format attributes are
appropriate may not be detected.
-Wmissing-noreturn-Wno-missing-noreturnnoreturn.
Note these are only possible candidates, not absolute ones. Care should
be taken to manually verify functions actually do not ever return before
adding the noreturn attribute, otherwise subtle code generation
bugs could be introduced. You will not get a warning for main in
hosted C environments.
-Wmissing-prototypes-Wno-missing-prototypes-Wmultichar-Wno-multichar-Wnested-externs-Wno-nested-externsextern declaration is encountered within a function.
-Wno-cast-qualconst char * is cast
to an ordinary char *.
-Wno-format-extra-argsprintf or scanf format function. The C standard specifies
that such arguments are ignored.
Where the unused arguments lie between used arguments that are
specified with $ operand number specifications, normally
warnings are still given, since the implementation could not know what
type to pass to va_arg to skip the unused arguments. However,
in the case of scanf formats, this option will suppress the
warning if the unused arguments are all pointers, since the Single
Unix Specification says that such unused arguments are allowed.
-Wno-format-y2kstrftime
formats which may yield only a two-digit year.
-Wlong-long-Wno-long-long-Wnonnullnonnull function attribute.
-Wnonnull is included in -Wall and -Wformat.
-Wno-non-template-friend-Wnon-virtual-dtor-Wno-non-virtual-dtor-Wno-pmf-conversions-Wold-style-cast-Wno-old-style-cast-Woverloaded-virtual-Wno-overloaded-virtual struct A {
virtual void f();
};
struct B: public A {
void f(int);
};
the A class version of f is hidden in B, and code
like:
B* b;
b->f();
will fail to compile.
-Wpacked-Wno-packedf.x in struct bar
will be misaligned even though struct bar does not itself
have the packed attribute:
struct foo {
int x;
char a, b, c, d;
} __attribute__((packed));
struct bar {
char z;
struct foo f;
};
-Wpadded-Wno-padded-Wparentheses-Wno-parenthesesAlso warn if a comparison like x<=y<=z appears; this is equivalent to (x<=y ? 1 : 0) <= z, which is a different interpretation from that of ordinary mathematical notation.
Also warn about constructions where there may be confusion as to which
if statement an else branch belongs. Here is an example of
such a case:
{
if (a)
if (b)
foo ();
else
bar ();
}
In C, every else branch belongs to the innermost possible if
statement, which in this example is if (b). This is often not
what the programmer expected, as illustrated in the above example by
indentation the programmer chose. When there is the potential for this
confusion, the compiler will issue a warning when this flag is specified.
To eliminate the warning, add explicit braces around the innermost
if statement so there is no way the else could belong to
the enclosing if. The resulting code would look like this:
{
if (a)
{
if (b)
foo ();
else
bar ();
}
}
This warning is enabled by -Wall.
-Wpointer-arith-Wno-pointer-arithvoid. GNU C assigns these types a size of 1, for
convenience in calculations with void * pointers and pointers
to functions.
-Wredundant-decls-Wno-redundant-decls-Wreorder-Wno-reorder struct A {
int i;
int j;
A(): j (0), i (1) { }
};
The compiler will rearrange the member initializers for i
and j to match the declaration order of the members, emitting
a warning to that effect. This warning is enabled by -Wall.
-Wreturn-type-Wno-return-typeint. Also warn about any return statement with no
return-value in a function whose return-type is not void.
For C, also warn if the return type of a function has a type qualifier
such as const. Such a type qualifier has no effect, since the
value returned by a function is not an lvalue. ISO C prohibits
qualified void return types on function definitions, so such
return types always receive a warning even without this option.
For C++, a function without return type always produces a diagnostic message, even when -Wno-return-type is specified. The only exceptions are main and functions defined in system headers.
This warning is enabled by -Wall.
-Wsequence-point-Wno-sequence-pointThe C and C++ standards defines the order in which expressions in a C/C++
program are evaluated in terms of sequence points, which represent
a partial ordering between the execution of parts of the program: those
executed before the sequence point, and those executed after it. These
occur after the evaluation of a full expression (one which is not part
of a larger expression), after the evaluation of the first operand of a
&&, ||, ? : or , (comma) operator, before a
function is called (but after the evaluation of its arguments and the
expression denoting the called function), and in certain other places.
Other than as expressed by the sequence point rules, the order of
evaluation of subexpressions of an expression is not specified. All
these rules describe only a partial order rather than a total order,
since, for example, if two functions are called within one expression
with no sequence point between them, the order in which the functions
are called is not specified. However, the standards committee have
ruled that function calls do not overlap.
It is not specified when between sequence points modifications to the values of objects take effect. Programs whose behavior depends on this have undefined behavior; the C and C++ standards specify that “Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.”. If a program breaks these rules, the results on any particular implementation are entirely unpredictable.
Examples of code with undefined behavior are a = a++;, a[n]
= b[n++] and a[i++] = i;. Some more complicated cases are not
diagnosed by this option, and it may give an occasional false positive
result, but in general it has been found fairly effective at detecting
this sort of problem in programs.
The standard is worded confusingly, therefore there is some debate over the precise meaning of the sequence point rules in subtle cases. Links to discussions of the problem, including proposed formal definitions, may be found on the GCC readings page, at http://gcc.gnu.org/readings.html.
This warning is enabled by -Wall for C and C++.
-Wshadow-Wno-shadow-Wsign-compare-Wno-sign-compare-Wsign-promo-Wno-sign-promo struct A {
operator int ();
A& operator = (int);
};
main ()
{
A a,b;
a = b;
}
In this example, G++ will synthesize a default A& operator =
(const A&);, while cfront will use the user-defined operator =.
-Wstrict-aliasing-Wno-strict-aliasing-Wstrict-prototypes-Wnostrict-prototypes-Wswitch-Wno-switchswitch statement has an index of enumerated type
and lacks a case for one or more of the named codes of that
enumeration. (The presence of a default label prevents this
warning.) case labels outside the enumeration range also
provoke warnings when this option is used.
This warning is enabled by -Wall.
-Wswitch-defaultswitch statement does not have a default
case.
-Wswitch-enumswitch statement has an enumerated type
and lacks a case for one or more of the named codes of that
enumeration.
-Wsystem-headers-Wno-system-headers-Wsynth (C++ Only)-Wno-synth (C++ Only)-Wtraditional-Wno-traditional<limits.h>.
Use of these macros in user code might normally lead to spurious
warnings, however the integrated preprocessor has enough context to
avoid warning in these cases.
switch statement has an operand of type long.
static function declaration follows a static one.
This construct is not accepted by some traditional C compilers.
__STDC__ to avoid missing
initializer warnings and relies on default initialization to zero in the
traditional C case.
PARAMS and
VPARAMS. This warning is also bypassed for nested functions
because that feature is already an extension and thus not relevant to
traditional C compatibility.
-Wtrigraphs-Wno-trigraphsThis section describes several environment variables that affect how the compiler operates. System environment variables can be used to affect the behavior of the x86 Open64 compilers. The following lists all such environment variables recognized by the compilers.
DO and PARALLEL_DO directives with
RUNTIME schedule type. OMP_SCHEDULE can be any of STATIC, DYNAMIC, or GUIDED.
Binary compatibility encompasses several related concepts:
The application binary interface implemented by a C or C++ compiler affects code generation and runtime support for:
In addition, the application binary interface implemented by a C++ compiler affects code generation and runtime support for:
Some x86 Open64 compilation options cause the compiler to generate code that does not conform to the platform's default ABI. Other options cause different program behavior for implementation-defined features that are not covered by an ABI. These options are provided for consistency with other compilers that do not follow the platform's default ABI or the usual behavior of implementation-defined features for the platform. Be very careful about using such options.
Most platforms have a well-defined ABI that covers C code, but ABIs that cover C++ functionality are not yet common.
Starting with x86 Open64 4.2, the Open64 binary conventions for C++ are based on a written, vendor-neutral C++ ABI that was designed to be specific to x86-64 platforms but also includes generic specifications that apply to any i386 platform. This C++ ABI is also implemented by other compiler vendors on some platforms, notably GNU/Linux® and BSD systems. We have tried hard to provide a stable ABI that will be compatible with future GCC i386 and x86-64 releases, but it is possible that we will encounter problems that make this difficult. Such problems could include different interpretations of the C++ ABI by different vendors, bugs in the ABI, or bugs in the implementation of the ABI in different compilers.
The C++ library used with a C++ compiler includes the Standard C++ Library, with functionality defined in the C++ Standard, plus language runtime support. The runtime support is included in a C++ ABI, but there is no formal ABI for the Standard C++ Library. Two implementations of that library are interoperable if one follows the de-facto ABI of the other and if they are both built with the same compiler, or with compilers that conform to the same ABI for C++ compiler and runtime support.
When x86 Open64 and another C++ compiler conform to the same C++ ABI, but the implementations of the Standard C++ Library that they normally use do not follow the same ABI for the Standard C++ Library, object files built with those compilers can be used in the same program only if they use the same C++ library. This requires specifying the location of the C++ library header files when invoking the compiler whose usual library is not being used. The location of the x86 Open64 C++ header files depends on how the x86 Open64 build was configured, but can be seen by using the x86 Open64 -v option. With default configuration options for x86 Open64 4.2 the compile line for a different C++ compiler needs to include
-Iopen64_install_directory/include/c++/4.2
Similarly, compiling code with x86 Open64 that must use a C++ library other than the GNU C++ library requires specifying the location of the header files for that other library.
The most straightforward way to link a program to use a particular C++ library is to use a C++ driver that specifies that C++ library by default. The openCC driver, for example, tells the linker where to find the Open64 C++ library (libstdc++) plus the other libraries and startup files it needs, in the proper order.
If a program must use a different C++ library and it's not possible to do the final link using a C++ driver that uses that library by default, it is necessary to tell openCC the location and name of that library. It might also be necessary to specify different startup files and other runtime support libraries, and to suppress the use of the Open64 support libraries with one or more of the options -nostdlib, -nostartfiles, and -nodefaultlibs.
If you want to have more free software a few years from now, it makes sense for you to help encourage people to contribute funds for its development. The most effective approach known is to encourage commercial redistributors to donate.
Users of free software systems can boost the pace of development by encouraging for-a-fee distributors to donate part of their selling price to free software developers—the Free Software Foundation, and others.
The way to convince distributors to do this is to demand it and expect it from them. So when you compare distributors, judge them partly by how much they give to free software development. Show distributors they must compete to be the one who gives the most.
To make this approach work, you must insist on numbers that you can compare, such as, “We will donate ten dollars to the Frobnitz project for each disk sold.” Don't be satisfied with a vague promise, such as “A portion of the profits are donated,” since it doesn't give a basis for comparison.
Even a precise fraction “of the profits from this disk” is not very meaningful, since creative accounting and unrelated business decisions can greatly alter what fraction of the sales price counts as profit. If the price you pay is $50, ten percent of the profit is probably less than a dollar; it might be a few cents, or nothing at all.
Some redistributors do development work themselves. This is useful too; but to keep everyone honest, you need to inquire how much they do, and what kind. Some kinds of development make much more long-term difference than others. For example, maintaining a separate version of a program contributes very little; maintaining the standard version of a program for the whole community contributes much. Easy new ports contribute little, since someone else would surely do them; difficult ports such as adding a new CPU to the GNU Compiler Collection contribute more; major new features or packages contribute the most.
By establishing the idea that supporting further development is “the proper thing to do” when distributing free software for a fee, we can assure a steady flow of resources into making more free software.
Copyright © 1994 Free Software Foundation, Inc.
Verbatim copying and redistribution of this section is permitted
without royalty; alteration is not permitted.
Copyright © 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the program's name and a brief idea of what it does.
Copyright (C) year name of author
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands show w and show c should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than show w and show c; they could even be mouse-clicks or menu items—whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.
Copyright © 2000,2001,2002 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ascii without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with...Texts.” line with this:
with the Invariant Sections being list their titles, with
the Front-Cover Texts being list, and with the Back-Cover Texts
being list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
Open64's command line options are indexed here without any initial - or --. Where an option has both positive and negative forms (such as -foption and -fno-option), relevant entries in the manual are indexed under the most appropriate form; it may sometimes be useful to look up both forms.
###: Overall OptionsA: Preprocessor Optionsalign: Language Independent Optionsalign32: Language Independent Optionsalign64: Language Independent Optionsansi: C Dialect Optionsansi: Standardsansi: Fortran Dialect Optionsapo: Global Optionsar: Link Optionsauto-use: Fortran Dialect Optionsbackslash: Language Independent Optionsbyteswapio: Fortran Dialect OptionsC: Diagnostic OptionsC: Preprocessor Optionsc: Link Optionsc: Overall OptionsCG:: Code Gen OptionsCG:cmp_peep: Code Gen OptionsCG:compute_to: Code Gen OptionsCG:cse_regs: Code Gen OptionsCG:gcm: Code Gen OptionsCG:inflate_reg_request: Code Gen OptionsCG:load_exe: Code Gen OptionsCG:local_sched_alg: Code Gen OptionsCG:locs_best: Code Gen OptionsCG:locs_reduce_prefetch: Code Gen OptionsCG:locs_shallow_depth: Code Gen OptionsCG:movti: Code Gen OptionsCG:p2align: Code Gen OptionsCG:p2align_freq: Code Gen OptionsCG:perfer_legacy_regs: Code Gen OptionsCG:post_local_sched: Code Gen OptionsCG:pre_local_sched: Code Gen OptionsCG:prefetch: Code Gen OptionsCG:ptr_load_use: Code Gen OptionsCG:push_pop_int_saved_regs: Code Gen OptionsCG:sse_cse_regs: Code Gen OptionsCG:unroll_fb_req: Code Gen OptionsCG:use_prefetchnta: Code Gen OptionsCG:use_test: Code Gen Optionsclist: Diagnostic OptionsCLIST:: Diagnostic OptionsCLIST:dotc_file: Diagnostic OptionsCLIST:doth_file: Diagnostic OptionsCLIST:emit_pfetch: Diagnostic OptionsCLIST:linelength: Diagnostic OptionsCLIST:show: Diagnostic OptionscolN: Fortran Dialect Optionsconvert: Fortran Dialect Optionscopyright: Overall Optionscpp: Preprocessor Optionsd: Debugging OptionsD: Preprocessor Optionsd: Fortran Dialect OptionsD: Preprocessor OptionsdD: Preprocessor OptionsdD: Debugging Optionsdefault64: Fortran Dialect OptionsdI: Preprocessor OptionsdI: Debugging OptionsdM: Preprocessor OptionsdM: Debugging OptionsdN: Debugging OptionsdN: Preprocessor Optionsdumpversion: Overall OptionsE: Overall OptionsE: Link Optionsextend-source: Fortran Dialect Optionsfabi-version: C Dialect Optionsfb-create: FDO Optionsfb-opt: FDO Optionsfb-phase: FDO Optionsfcheck-new: C Dialect Optionsfcoco: Preprocessor Optionsfe: Preprocessor Optionsfexceptions: C Dialect Optionsffast-math: General Optimizationsffast-stdlib: Link Optionsffloat-store: General Optimizationsffortran-bounds-check: Diagnostic Optionsffreestanding: C Warningfgnu-exceptions: C Dialect Optionsfgnu-keywords: C Dialect Optionsfimplicit-inline-templates: IPO Optionsfimplicit-templates: IPO Optionsfinhibit-size-directive: Language Independent Optionsfinline: IPO Optionsfinline-functions: IPO Optionsfinstrument-functions: FDO Optionsfkeep-inline-functions: IPO Optionsflist: Diagnostic OptionsFLIST:: Diagnostic OptionsFLIST:ansi_fomat: Diagnostic OptionsFLIST:emit_pfetch: Diagnostic OptionsFLIST:ftn_file: Diagnostic OptionsFLIST:linelength: Diagnostic OptionsFLIST:show: Diagnostic Optionsfms-extensions: C Dialect Optionsfno-asm: Assembler Optionsfno-builtin: C Dialect Optionsfno-builtin: C Warningfno-check-new: C Dialect Optionsfno-common: C Dialect Optionsfno-exceptions: C Dialect Optionsfno-fast-math: General Optimizationsfno-fast-stdlib: Link Optionsfno-gnu-exceptions: C Dialect Optionsfno-gnu-keywords: C Dialect Optionsfno-ident: Language Independent Optionsfno-implicit-inline-templates: IPO Optionsfno-implicit-templates: IPO Optionsfno-inline: IPO Optionsfno-inline-functions: IPO Optionsfno-math-errno: General Optimizationsfno-permissive: Diagnostic Optionsfno-preprocessed: Preprocessor Optionsfno-rtti: C Dialect Optionsfno-signed-bitfields: C Dialect Optionsfno-signed-char: C Dialect Optionsfno-strict-aliasing: C Dialect Optionsfno-unsafe-math-optimizations: General Optimizationsfno-unwind-tables: Language Independent Optionsfpack-struct: C Dialect Optionsfpermissive: Diagnostic Optionsfpic: Language Independent OptionsfPIC: Language Independent Optionsfprefix-function-name: C Dialect Optionsfpreprocessed: Preprocessor Optionsfprofile-arcs: Debugging Optionsfrandom-seed: Debugging Optionsfrtti: C Dialect Optionsfshort-double: C Dialect Optionsfshort-enums: C Dialect Optionsfshort-wchar: C Dialect Optionsfsigned-bitfields: C Dialect Optionsfsigned-char: C Dialect Optionsfstrict-aliasing: C Dialect Optionsftest-coverage: Debugging Optionsftpp: Preprocessor Optionsfullwarn: Diagnostic Optionsfunsafe-math-optimizations: General Optimizationsfunwind-tables: Language Independent Optionsfuse-cxa-atexit: C Dialect Optionsg: Debugging Optionsg0: Debugging Optionsg1: Debugging Optionsg2: Debugging Optionsg3: Debugging Optionsgdwarf-2: Debugging Optionsgdwarf-20: Debugging Optionsgdwarf-21: Debugging Optionsgdwarf-22: Debugging Optionsgdwarf-23: Debugging Optionsgnu: C Dialect OptionsGRA: Code Gen OptionsGRA:home: Code Gen OptionsGRA:optimize_boundary: Code Gen OptionsGRA:prioritize_by_density: Code Gen OptionsGRA:unspill: Code Gen OptionsH: Link Optionshelp: Overall Optionshelp:: Overall OptionsHP: Language Independent OptionsHP:: Language Independent OptionsHP:bdt: Language Independent OptionsHP:heap: Language Independent OptionsHUGEPAGE: Language Independent OptionsHUGEPAGE:: Language Independent OptionsHUGEPAGE:bdt: Language Independent OptionsHUGEPAGE:heap: Language Independent OptionsI: Directory Optionsignore-suffix: Language Independent OptionsINLINE: IPO Optionsinline: IPO OptionsINLINE:aggressive: IPO OptionsINLINE:all: IPO OptionsINLINE:list: IPO OptionsINLINE:must: IPO OptionsINLINE:never: IPO OptionsINLINE:none: IPO OptionsINLINE:preempt: IPO Optionsipa: IPO OptionsIPA: IPO OptionsIPA:: IPO OptionsIPA:addressing: IPO OptionsIPA:aggr_cprop: IPO OptionsIPA:alias: IPO OptionsIPA:callee_limit: IPO OptionsIPA:cgi: IPO OptionsIPA:clone_list: IPO OptionsIPA:common_pad_size: IPO OptionsIPA:cprop: IPO OptionsIPA:ctype: IPO OptionsIPA:depth: IPO OptionsIPA:dfe: IPO OptionsIPA:dve: IPO OptionsIPA:echo: IPO OptionsIPA:field_reorder: IPO OptionsIPA:forcedepth: IPO OptionsIPA:ignore_lang: IPO OptionsIPA:inline: IPO OptionsIPA:keeplight: IPO OptionsIPA:linear: IPO OptionsIPA:map_limit: IPO OptionsIPA:max_jobs: IPO OptionsIPA:maxdepth: IPO OptionsIPA:min_hotness: IPO OptionsIPA:multi_clone: IPO OptionsIPA:node_bloat: IPO OptionsIPA:plimit: IPO OptionsIPA:pu_reorder: IPO OptionsIPA:relopt: IPO OptionsIPA:small_pu: IPO OptionsIPA:sp_partition: IPO OptionsIPA:space: IPO OptionsIPA:specfile: IPO OptionsIPA:use_intrinsic: IPO Optionsiquote: Directory Optionsisysroot: Directory Optionsisystem: Directory Optionskeep: Overall OptionsL: Directory Optionsl: Link OptionsLANG:: Language Feature OptionsLANG:copyinout: Language Feature OptionsLANG:formal_deref_unsafe: Language Feature OptionsLANG:global_asm: Language Feature OptionsLANG:heap_allocation_threshold: Language Feature OptionsLANG:IEEE_minus_zero: Language Feature OptionsLANG:IEEE_save: Language Feature OptionsLANG:recursive: Language Feature OptionsLANG:rw_const: Language Feature OptionsLANG:short_circuit_conditionals: Language Feature OptionsLIST:: Overall OptionsLIST:all_options: Overall OptionsLIST:notes: Overall OptionsLIST:options: Overall OptionsLIST:symbols: Overall OptionsLNO:: LNO OptionsLNO:apo_use_feedback: LNO OptionsLNO:assoc: LNO OptionsLNO:assume_unknown_trip_count: LNO OptionsLNO:blocking: LNO OptionsLNO:blocking_size: LNO OptionsLNO:build_scalar_reductions: LNO OptionsLNO:cmp: LNO OptionsLNO:cmp, dmp: LNO OptionsLNO:cs: LNO OptionsLNO:dmp: LNO OptionsLNO:fission: LNO OptionsLNO:fu: LNO OptionsLNO:full_unroll: LNO OptionsLNO:full_unroll_outer: LNO OptionsLNO:full_unroll_size: LNO OptionsLNO:fusion: LNO OptionsLNO:fusion_peeling_limit: LNO OptionsLNO:gather_scatter: LNO OptionsLNO:hoistif: LNO OptionsLNO:ignore_feedback: LNO OptionsLNO:ignore_pragmas: LNO OptionsLNO:interchange: LNO OptionsLNO:is_mem: LNO OptionsLNO:local_pad_size: LNO OptionsLNO:ls: LNO OptionsLNO:minvar: LNO OptionsLNO:minvariant: LNO OptionsLNO:non_blocking_loads: LNO OptionsLNO:oinvar: LNO OptionsLNO:opt: LNO OptionsLNO:ou: LNO OptionsLNO:ou_deep: LNO OptionsLNO:ou_further: LNO OptionsLNO:ou_max: LNO OptionsLNO:ou_prod_max: LNO OptionsLNO:outer: LNO OptionsLNO:outer_unroll: LNO OptionsLNO:outer_unroll_deep: LNO OptionsLNO:outer_unroll_max: LNO OptionsLNO:parallel_overhead: LNO OptionsLNO:pf: LNO OptionsLNO:prefetch: LNO OptionsLNO:prefetch_ahead: LNO OptionsLNO:prefetch_manual: LNO OptionsLNO:prefetch_verbose: LNO OptionsLNO:processors: LNO OptionsLNO:ps: LNO OptionsLNO:pwr2: LNO OptionsLNO:sclrze: LNO OptionsLNO:simd: LNO OptionsLNO:simd_reduction: LNO OptionsLNO:simd_verbose: LNO OptionsLNO:svr_phase1: LNO OptionsLNO:tlb: LNO OptionsLNO:tlbcmp: LNO OptionsLNO:tlbcmp, tlbdmp: LNO OptionsLNO:tlbdmp: LNO OptionsLNO:trip_count: LNO OptionsLNO:trip_count_assumed_when_unknown: LNO OptionsLNO:unswitch: LNO OptionsLNO:unswitch_verbose: LNO OptionsLNO:vintr: LNO OptionsLNO:vintr_verbose: LNO OptionsLNO_outer_unroll_further: LNO OptionsM: Preprocessor Optionsm32: Submodel Optionsm3dnow: Submodel Optionsm64: Submodel Optionsmacro-expand: Preprocessor Optionsmarch: Submodel Optionsmcmodel: Submodel Optionsmcmodel=medium: Submodel Optionsmcmodel=small: Submodel Optionsmcpu: Submodel OptionsMD: Preprocessor OptionsMDtarget: Preprocessor OptionsMDupdate: Preprocessor OptionsMF: Preprocessor OptionsMG: Preprocessor OptionsMM: Preprocessor OptionsMMD: Preprocessor Optionsmmo-msse3: Submodel Optionsmno-3dnow: Submodel Optionsmno-msse: Submodel Optionsmno-msse4a: Submodel Optionsmno-sse2: Submodel Optionsmp: General OptimizationsMP: Preprocessor OptionsMQ: Preprocessor Optionsmsse: Submodel Optionsmsse2: Submodel Optionsmsse3: Submodel Optionsmsse4a: Submodel OptionsMT: Preprocessor Optionsmtune: Submodel Optionsmx87-precision: General Optimizationsno-gcc: Preprocessor Optionsno-opencc: Language Independent Optionsnobool: Language Independent Optionsnocpp: Preprocessor Optionsnodefaultlibs: Link Optionsnoexpopt: General Optimizationsnoextend-source: Fortran Dialect Optionsnog77mangle: Fortran Dialect Optionsnoinline: IPO Optionsnostartfiles: Link Optionsnostdinc: Link Optionsnostdinc: Directory Optionsnostdinc++: Link Optionsnostdlib: Link OptionsO: Global Optionso: Overall OptionsO0: Global OptionsO1: Global OptionsO2: Global OptionsO3: Global Optionsobjectlist: Link OptionsOfast: Global OptionsOfast: General Optimizationsopencc: Language Independent Optionsopenmp: General OptimizationsOPT:: General OptimizationsOPT:alias: General OptimizationsOPT:align_unsafe: General OptimizationsOPT:asm_memory: General OptimizationsOPT:bb: General OptimizationsOPT:cis: General OptimizationsOPT:cyg_instr: General OptimizationsOPT:div_split: General OptimizationsOPT:early _intrinsics: General OptimizationsOPT:early_mp: General OptimizationsOPT:fast_bit_intrinsics: General OptimizationsOPT:fast_complex: General OptimizationsOPT:fast_exp: General OptimizationsOPT:fast_io: General OptimizationsOPT:fast_math: General OptimizationsOPT:fast_nint: General OptimizationsOPT:fast_sqrt: General OptimizationsOPT:fast_stdlib: General OptimizationsOPT:fast_trunc: General OptimizationsOPT:fold_reassociate: General OptimizationsOPT:fold_unsafe_relops: General OptimizationsOPT:fold_unsigned_relops: General OptimizationsOPT:goto: General OptimizationsOPT:IEEE_a: General OptimizationsOPT:IEEE_arith: General OptimizationsOPT:IEEE_arithmetic: General OptimizationsOPT:IEEE_NaN_inf: General OptimizationsOPT:inline_intrinsics: General OptimizationsOPT:keep_ext: General OptimizationsOPT:malloc_alg: General OptimizationsOPT:malloc_algorithm: General OptimizationsOPT:Olimit: General OptimizationsOPT:pad_common: General OptimizationsOPT:recip: General OptimizationsOPT:reorg_common: General OptimizationsOPT:ro: General OptimizationsOPT:roundoff: General OptimizationsOPT:rsqrt: General OptimizationsOPT:space: General OptimizationsOPT:speculate: General OptimizationsOPT:transform_to_memlib: General OptimizationsOPT:treeheight: General OptimizationsOPT:unroll_analysis: General OptimizationsOPT:unroll_level: General OptimizationsOPT:unroll_size: General OptimizationsOPT:unroll_times_max: General OptimizationsOPT:wrap_around_unsafe_opt: General OptimizationsOs: Global OptionsP: Preprocessor Optionsp: Debugging Optionspad-char-literals: Fortran Dialect Optionspedantic: Standardspedantic-errors: Standardspedantic-errors: Diagnostic Optionspg: Debugging Optionsprofile: Debugging Optionsr: Fortran Dialect Optionsr: Overall OptionsS: Link OptionsS: Overall Optionsshared: Link Optionsshared-libgcc: Link Optionsshow: Overall Optionsshow-defaults: Overall Optionsshow0: Overall Optionsshowt: Overall Optionsstatic: Link Optionsstatic-data: Link Optionsstatic-libgcc: Link Optionsstd: C Dialect Optionsstd: Standardsstdinc: Link Optionssubverbose: Diagnostic Optionssymbolic: Link OptionsTENV:: Target OptionsTENV:frame_pointer: Target OptionsTENV:simd_dmask: Target OptionsTENV:simd_imask: Target OptionsTENV:simd_omask: Target OptionsTENV:simd_pmask: Target OptionsTENV:simd_umask: Target OptionsTENV:simd_zmask: Target OptionsTENV:X: Target Optionstraditional: C Dialect Optionstrapuv: Diagnostic OptionsU: Language Independent OptionsU: Preprocessor Optionsu: Fortran Dialect Optionsv: Overall Optionsversion: Overall Optionsw: Language IndepWa: Assembler OptionsWaggregate-return: C WarningWall: Language IndepWbad-function-cast: Language IndepWcast-align: C WarningWchar-subscripts: C WarningWcomment: C WarningWconversion: C WarningWdeclaration-after-statement: C WarningWdeprecated: Language IndepWdisabled-optimization: Language IndepWdiv-by-zero: Language IndepWendif-labels: Language IndepWerror: Language IndepWfloat-equal: Language IndepWformat: C WarningWformat-nonliteral: C WarningWformat-security: C Warningwid-clash: C WarningWimplicit: C WarningWimplicit-function-declaration: C WarningWimplicit-int: C WarningWimport: Language IndepWinline: C WarningWl: Link OptionsWlarger-than: Language IndepWlong-long: C WarningWmain: C WarningWmissing-braces: C WarningWmissing-declarations: C WarningWmissing-format-attribute: C WarningWmissing-noreturn: C WarningWmissing-prototypes: C WarningWmultichar: C WarningWnested-externs: C WarningWno-cast-align: C WarningWno-cast-qual: C WarningWno-char-subscripts: C WarningWno-comment: C WarningWno-conversion: C WarningWno-deprecated: Language IndepWno-deprecated-declarations: Language IndepWno-disabled-optimization: Language IndepWno-div-by-zero: Language IndepWno-endif-labels: Language IndepWno-error: Language IndepWno-float-equal: Language IndepWno-format: C WarningWno-format-extra-args: C WarningWno-format-nonliteral: C WarningWno-format-security: C WarningWno-format-y2k: C Warningwno-id-clash: C WarningWno-implicit: C WarningWno-implicit-function-declaration: C WarningWno-implicit-int: C WarningWno-import: Language IndepWno-inline: C WarningWno-larger-than: Language IndepWno-long-long: C WarningWno-main: C WarningWno-missing-braces: C WarningWno-missing-declarations: C WarningWno-missing-format-attribute: C WarningWno-missing-noreturn: C WarningWno-missing-prototypes: C WarningWno-multichar: C WarningWno-nested-externs: C WarningWno-non-template-friend: C WarningWno-non-virtual-dtor: C WarningWno-old-style-cast: C WarningWno-overloaded-virtual: C WarningWno-packed: C WarningWno-padded: C WarningWno-parentheses: C WarningWno-pmf-conversions: C WarningWno-pointer-arith: C WarningWno-redundant-decls: C WarningWno-reorder: C WarningWno-return-type: C WarningWno-sequence-point: C WarningWno-shadow: C WarningWno-sign-compare: C WarningWno-sign-promo: C WarningWno-strict-aliasing: C WarningWno-strict-prototypes: C WarningWno-switch: C WarningWno-synth: C WarningWno-system-headers: C WarningWno-traditional: C WarningWno-trigraphs: C WarningWno-undef: Language IndepWno-uninitialized: Language IndepWno-unknown-pragmas: Language IndepWno-unreachable-code: Language IndepWno-unused: Language IndepWno-unused value: Language IndepWno-unused-label: Language IndepWno-unused-parameter: Language IndepWno-unused-variable: Language IndepWno-unused_function: Language IndepWno-write-strings: Language IndepWnon-virtual-dtor: C WarningWnonnull: C Warningwoff: Language Indepwoffall: Language Indepwoffoptions: Language IndepWold-style-cast: C WarningWOPT: Global OptionsWOPT:aggstr: Global OptionsWOPT:const_pre: Global OptionsWOPT:if_conv: Global OptionsWOPT:ivar_pre: Global OptionsWOPT:mem_opnds: Global OptionsWOPT:retype_expr: Global OptionsWOPT:unroll: Global OptionsWOPT:val: Global OptionsWoverloaded-virtual: C WarningWp: Preprocessor OptionsWpacked: C WarningWpadded: C WarningWparentheses: C WarningWpointer-arith: C WarningWredundant-decls: C WarningWreorder: C WarningWreturn-type: C WarningWsequence-point: C WarningWshadow: C WarningWsign-compare: C WarningWsign-promo: C WarningWstrict-aliasing: C WarningWstrict-prototypes: C WarningWswitch: C WarningWswitch-default: C WarningWswitch-enum: C WarningWsynth: C WarningWsystem-headers: C WarningWtraditional: C WarningWtrigraphs: C WarningWundef: Language IndepWuninitialized: Language IndepWunknown-pragmas: Language IndepWunreachable-code: Language IndepWunused: Language IndepWunused-function: Language IndepWunused-label: Language IndepWunused-parameter: Language IndepWunused-value: Language IndepWunused-variable: Language IndepWwrite-strings: Language IndepXlinker: Link Optionszerouv: Diagnostic Options__STDC_HOSTED__: Standardsc++: Invoking openCClongjmp warnings: Language IndepopenCC: Invoking openCC[1] On some systems, gcc -shared needs to build supplementary stub code for constructors to work. On multi-libbed systems, gcc -shared must select the correct support libraries to link against. Failing to supply the correct flags may lead to subtle defects. Supplying them in cases where they are not necessary is innocuous.