Using the x86 Open64 Compiler Suite

This file documents the use of the x86 Open64 version 4.2.4 compilers.

© 2010 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.4 .

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”.

1. The x86 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 many advanced optimizations including global optimization, vectorization, interprocedural analysis, feedback directed optimizations and loop transformations. The x86 Open64 compiler system also provides 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.

1.1 Programming Languages Supported

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.

1.2 Language Standards Supported

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 C/C++ Application Binary Interface (ABI) as defined by GCC,
• - and with the x86-32 ABI and x86-64 ABI.

The compiler supports most of the generally used command-line options supported by GCC and a number of the GNU extensions.

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:

• - ISO/IEC TR 15580: Fortran floating point exception handling.
• - ISO/IEC TR 15581: Fortran enhanced data type facilities.
• - ISO/IEC 1539-2: Varying length character strings.
• - ISO/IEC 1539-3: Conditional compilation.
• - ISO/IEC 1539:1991 (Fortran 90) Programming languages-Fortran.

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 conformance with ISO/IEC 1539-1:2004 (Fortran 2003) Programming Languages-Fortran.

1.3 How To Get Help

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:

• - Comprehensive product documentation
• - Technical user forums
• - User friendly knowledge-base
• - AMD ’Service Request’ help desk

AMD provides support of the x86 Open64 Compiler Suite distributed 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 distributed 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.

1.4 Reporting Bugs

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.

1.4.1 Have You Found a Bug?

If you are not sure whether you have found a bug, here are some guidelines:

• -
• - If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash.
• - If the compiler produces invalid assembly code, for any input whatever (except an asm statement), that is a compiler bug, unless the compiler reports errors (not just warnings) which would ordinarily prevent the assembler from being run.
• - If the compiler produces valid assembly code that does not correctly execute the input source code, that is a compiler bug.

  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 non-optimizing 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.

• - If the compiler produces an error message for valid input, that is a compiler bug.
• - If the compiler does not produce an error message for invalid input, that is a compiler bug. However, you should note that your idea of “invalid input” might be someone else’s idea of “an extension” or “support for traditional practice”.
• - If you are an experienced user of one of the languages x86 Open64 supports, your suggestions for improvement of Open64 are welcome in any case.

1.4.2 How and where to Report Bugs

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.

1.5 Contributing to Open64 Development

Supported binary releases and source snapshots of Open64 are available at:

http://developer.amd.com/cpu/open64.

These sources are periodically merged into the main SVN tree at:

http://svn.open64.net.

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.

2. Using the x86 Open64 Compiler

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.

2.1 Using the x86 Open64 C/C++ 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

2.1.1 Pre-defined Macros

The C/C++ compiler predefines certain macros for the preprocessor. Follow these steps to find out what these macros are:

1. Compile your program with the switches -dD and -keep.
2. Look in the resulting .i file to see the list of pre-defined macros and their corresponding definitions.

For example:

$ opencc -dD -keep foo.c
$ cat foo.i

2.1.2 Pragmas

C/C++ pragmas enable the user to disable the effects of a command line option or apply new options to a selected part of a program without affecting the program as a whole. Pragmas are part of the C/C++ language, however, the meanings of the pragmas are implementation-specific.

2.1.2.1 Pragma pack

The syntax is:

#pragma pack (n)

This pragma specifies that the next structure should have each of their fields aligned to an alignment of n bytes, where n = 0, 1, 2, 4, 8, or 16. This only applies if its natural alignment is not smaller than n. When n = 0, the compiler returns to the default alignment for the subsequent struct definitions.

2.1.2.2 Unsupported GCC Extensions

The x86 Open64 C/C++ compiler supports majority of the C/C++ extensions supported by GCC version 4.2.0, except for the following extensions:

For C/C++:

• - Complex integer data types (_Complex int)
• - Structures that are generated/instantiated on the fly
• - Indirect goto to an address of a label outside of the current block scope
• - Nested functions
• - Many of the __builtin_ functions
• - Attributes init_priority and java_interface
• - Java-style exceptions

2.2 Using the x86 Open64 Fortran Compiler

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

2.2.1 Fixed-form and Free-form Fortran

Fixed form is the older form where character positions (columns) are reserved as follows:

Free form is much less restrictive and has the following features:

• - No limitations on line length
• - An ’&’ at the end of the line indicates that the next line is a continuation.
• - A ’!’ anywhere on a line indicates a comment.

2.2.2 Pre-defined macros

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):

1. Compile your program with the switches -Wp,-dD -E.
2. The list of pre-defined macros and their corresponding definitions will be written to the stdout file.

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

2.2.3 Fortran Modules

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:

1. Modules must appear before their uses in the same source file.
2. Files containing modules that are to be used by other files must be compiled before the other files are compiled.
3. Files containing modules that are to be used by other files must appear before the other files in the same compilation command.

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.

2.2.3.1 Linking a Main Program Contained in a Library

When you are working with many object files, it’s convenient to place them all into a single library. So instead of specifying a long list of object files, you only have to specify the library when linking the program. The linker symbol for a main Fortran program is MAIN__ rather than main. This results in the linker not automatically importing the program from a library when using openf90 to link to the program. The program will abort. To prevent your program from aborting, you need to tell the linker explicitly to import the symbol MAIN__ (with two underscores):

$ openf90 -Wl, --undefined=MAIN__ objectlibrary.a 

2.2.3.2 Module Error Messages

Error messages appear as the first line in the module, regardless of where in the module the error actually occurs. The real error is reported after this standard message, as shown in the following example.

Here is a program, ‘hellow.f95’, which contains this module:

MODULE HELLO_WORLD
CONTAINS
SUBROUTINE HELLO_W( )
SPRINTZ *,"Hello, World!"
END SUBROUTINE HELLO_W
END MODULE HELLO_WORLD

Next compile the program containing the module:

$ openf95 hellow.f95
     MODULE HELLO_WORLD
        ^
openf95-855 openf95: ERROR HELLO_WORLD, File = hello_world.f95, Line = 1,Column = 9
  The compiler has detected errors in module "HELLO_WORLD". No module information
  file will be created for this module.
     SPRINTZ *,"Hello, World!"
         ^
openf95-724 openf95: ERROR HELLO_W, File = hello_world.f95, Line = 4,Column = 10
  Unknown statement. Expected assignment statement but found "*" instead of "=" or "=>".

openf95: Open64 Fortran Version 4.2(f14) Tue Apr 27,2010 22:41:48
openf95: 6 source lines
openf95: 2 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s)
openf95: "explain openf95-message number" gives more information about each message

Note that the real error is pointed out after the first error on line 1 is reported.

2.2.4 Extensions

The x86 Open64 supports the following extensions to the Fortran standard:

• - Promoting REAL and INTEGER Types
• - Cray Pointers
• - Directives (Prefetch and Change Optimization)

2.2.4.1 Promoting REAL and INTEGER Types

The following option is useful for porting from Cray code when integer and floating point data is 8-bytes long by default.

‘-r8’

Promotes the default representation for REAL type from 4 bytes to 8 bytes.

‘-i8’

Promotes the default representation for INTEGER type from 4 bytes to 8 bytes.

Consider the following when using this option:

• - Always check for type mismatches with external libraries.
• - The ‘-r8’ and ‘-i8’ flags do not affect variable declarations or constants that specify an explicit KIND. If a 4-byte default real or integer is passed into a subprogram that declares a KIND=4 integer or real, the results will be incorrect.

  The following example shows the correct usage of KIND:

  VAR1 = KIND(1)

  or

  VAR2 = KIND(0.0d0)

  If you try to use KIND = KIND(1), you will get the following error message:

  The left hand side of an assignment statement must be a variable or a function result

2.2.4.2 Cray Pointers

The Cray pointer provides a C-like pointer in Fortran for specifying dynamic objects. The Cray pointer differs from the Fortran pointer. Both the Cray and Fortran pointers use POINTER, but they are declared differently.

The Cray pointer is declared using:

POINTER ( <pointer>, <pointee> )

The "pointer" holds a memory address and the "pointee" is used to dereference the pointer.

The Fortran pointer is declared using:

POINTER :: [ <object)name> ]

The x86 Open64 uses the stricter Cray implementation of the Cray pointers. Specifically, x86 Open64 doesn’t treat pointers exactly like integers. For example, if you use p = ( (p+7) / 8) * 8 to align a pointer, the compiler flags this as an error.

2.2.4.3 Directives

Directives change the effects of certain command line options or default behavior of the compiler. While a command line option affects the entire source file being compiled, directives apply only to selected subroutines or loops. At the end of the selected portion of the program, the settings revert back to the command line options.

By default, directives within a file override the command line options. However, certain directives may have no effect unless additional options are present (for example, ‘-mp)’.

Following are options for changing this default:

Command line options to override directives:

-LNO:ignore_pragmas

Ignore directives contained within comments (such as !$OMP or C*$* PREFETCH_REF):

-no-directives

Scan the comments for directives:

-directives

Prefetch Directives

x86 Open64 supports the following prefetch directives:

C*$* PREFETCH(N [,N])

This directive specifies prefetching for each level of the cache.

N values:

0

Prefetching off (Default)

1

Prefetching on, but less aggressive than N=2.

2

Prefetching on, most aggressive. (Default when prefetch is on.)

Scope: Entire function containing the directive.

C*$* PREFETCH_MANUAL(N)

This directive specifies if manual prefetches (through directives) are respected or ignored.

N values:

0

Ignore manual prefetches

1

Respect manual prefetches

Scope: Entire function containing the directive.

C*$* PREFETCH_REF_DISABLE=A [, size=num]

This directive explicitly disables prefetching all references to array A in the current function. If enabled, the auto-prefetcher runs and ignores array A.

size=num

This optional argument is the size of the array references in this loop in Kbyte. This value must be a constant. Use the size for volume analysis.

Scope: Entire function containing the directive.

C*$* PREFETCH_REF=array-ref, [stride=[str] [,str]], [level=[lev] [,lev]], [kind=[rd/wr]], [size=[sz]]

This directive generates a single prefetch instruction to the specified memory location. In the current loop-nest, this directive searches for array references that match the supplied reference.

‘Found’

Reference is connected to this prefetch node with the specified parameters.

‘Not Found’

This prefetch node stays free-floating and is "loosely" scheduled.

The automatic prefetcher (if enabled) ignores all references to this array in this loop-nest.

If the size is supplied, the auto-prefetcher (if enabled) reduces the effective cache size by that amount.

The compiler attempts to issue one prefetch per stride iteration, but this cannot be guaranteed. Use redundant prefetches instead of transformations (such as inserting conditionals) that incur additional overhead.

This option uses the following arguments:

array-ref

Required. Array reference. For example: A(i,j)

str

Optional. Prefetches every str iterations of this loop. Default = 1.

lev

Optional. The level in memory hierarchy to prefetch.

1

Prefetch from L2 to L1 cache.

2

Prefetch from memory to L1 cache.

The default is lev=2.

rd/wr

Optional. Default is read/write.

sz

Optional. The size in Kbytes of the array referenced in this loop. This value must be a constant.

Scope: No scope. Only generates a prefetch instruction.

Changing Optimization Using Directives

Optimization flags can be changed by using directives. The directive form is: C*$* options <"list-of-options">

You can specify any number of these directives inside the scope of the function. Each directive affects only the optimization of the entire function in which it is specified. You can add to the literal string an unlimited number of different options by separating the options with a space and including the enclosing quotes. For the next function, all flags revert back to the settings specified in the compiler command line.

Following are some considerations for the options that are processed in this directive and their effects on the optimization:

• - No warning or error is given for options that are not processed.
• - Only options that affect optimizations are processed because these directive are processed only in the optimizing backend.
• - The phase invocation of the backend components is not affected. For example, specifying -O0 doesn’t suppress the invocation of the global optimizer. However, the invoked backend phases will honor the specified optimization level.
• - In addition to the optimization-level flags, only flags belonging to the following option groups are processed: -LNO, -OPT and -WOPT.

2.2.5 Varying Length Character Strings

x86 Open64 supports the ISO/IEC Standard 1539-2, which provides support for varying length character strings. You can download the module from the following location:

http://www.fortran.com/fortran/iso_varying_string.f95

2.2.6 Fortran 90 Dope Vector

Fortran provides constructs (for example, ubound and size for obtaining information about dynamically allocated objects, such as arrays and character strings. The compiler implements these constructs by maintaining information about the object in a data structure called a dope vector. Additional information can be found in the source distribution of the file: ‘clibinc/cray/dopevec.h’.

2.2.7 Bounds Checking

x86 Open64 can perform bounds checking on arrays. Use the -C option to generate an intermediate file:

$ openf95 -C foo.f90 -0 foo

The generated code checks all array accesses to ensure they are within range of the array boundaries. Accesses that fall out of range, results in a warning at runtime:

$ ./foo
lib-4961 : WARNING
  Unable to find error message (check NLSPATH, file lib.cat)
 a[11]= 0

If you want the resulting program to abort on the first bounds check violation, set the environment variable F90_BOUNDS_CHECK_ABORT to YES. However, this will still result in a second bound warning as follows:

lib-4961 : WARNING
  Subscript 11 is out of range for dimension 1 for array
  'A' at line 5 in file 'simple_array.f' with bounds 1:10.
 a[11]= -1

lib-4961 : WARNING
  Subscript 12 is out of range for dimension 1 for array
  'A' at line 7 in file 'simple_array.f' with bounds 1:10.
 a[11]= -1

Enable array bounds checking only for debugging since it significantly slows code performance, i.e., disable in production code that is performance sensitive.

2.2.8 Pseudo-random Numbers

The pseudo-random number generator (PRNG) is a non-linear additive feedback PRNG with a 32-entry long seed table.

The period of the PRNG is approximately 16*((2**32) -1).

2.2.9 Fortran KINDs Compatibility

The x86 Open64 may have some compatibility issues with source code developed for other compilers because different compilers represent types in various ways.

The Fortran KIND attribute gives the user flexibility in specifying the precision or size of a type. Currently, Fortran uses KINDS to declare types. The following example shows the recommended and portable way to use KIND to inquire its value:

integer :: var3_kind = kind(0.0d0)

In practice, some users set the actual values in their programs:

integer :: var3_kind = 7

Using this way is unportable since some compilers use different values for the KIND of a double-precision floating-point value.

The x86 Open64 and most other compilers use the convention that the KIND value is the number of bytes in the type. For floating point numbers:

KIND=4

32-bit floating point

KIND=8

64-bit floating point

However, this convention is incompatible with unportable programs written using GNU Fortran, g77. For floating-point numbers, g77 uses:

KIND=1

32-bit single precision

KIND=2

64-bit double precision

For integer numbers, g77 uses:

KIND=3

1 btye

KIND=4

2 bytes

KIND=1

4 btyes

KIND=2

8 bytes

Currently, there is no compatibility flag for unportable g77 programs. It is best to following the recommended way for finding the actual KIND values.

If your programs uses -i8 or -r8, refer to the "Promoting REAL and INTEGER Types" section for more details.

2.2.10 Runtime I/O Compatibility

This section describes how the x86 Open64 compiler interacts with files generated by the Fortran I/O libraries on other systems. These files may contain data in different formats than that generated or expected by codes compiled by the Open64 compiler.

2.2.10.1 Using the I/O Complication Flags

To help with I/O, use the following two compilation flags:

-byteswapio

This flag swaps bytes during I/O so that unformatted files on a little-endian processor are read and written in big-endian format (or vice versa).

-convert conversion

This flag controls the swapping of bytes during I/O so that unformatted files on a little-endian processor are read and written in big-endian format (or vice versa). Use this option when compiling the Fortran main program.

This flag takes one of the following arguments:

• … native - No conversion. Default
• … big_endian - Files are big endian.
• … little_endian - Files are little endian.

2.2.10.2 Reserved File Units

x86 Open64 reserves Fortran file units 5, 6, and 0.

2.3 Mixed Code

Generally when the argument data types and function return values agree, you can call a C/C++ function from Fortran and call a Fortran function from C/C++. Following are the calling considerations you should know about for mixed-code applications:

• - C++ functions containing objects with constructors and destructors - It is not possible to call such functions from either C or Fortran unless you initialize the main program from a C++ program where the constructor and destructor are correctly initialized.
• - Use extern "C" keyword to prevent "mangling" of function names - The C++ compiler mangles symbol names to implement overloading and adds to the data structures various information (such as virtual table pointer) that other languages cannot understand. When calling a C or Fortran function from C++, use the extern "C" keyword to declare the function in the C++ program. When calling a C++ function from C or Fortran, also use the extern "C" keyword to declare the C++ function.
• - Use the _cplusplus macro to allow a program or header file to work for both C and C++.
• - C++ member functions cannot be called from C or Fortran because C++ member functions cannot be declared extern.

2.3.1 Functions and Subroutines

Fortran, C, and C++ do not define functions and subroutines in the same way.

For a Fortran program calling a C or C++ function, the return value conventions are as follows:

• - When a C/C++ function returns a value, call it from Fortran as a function.
• - When a C/C++ function does not return a value, call it as a subroutine.

For a C/C++ program calling a Fortran function, the call should return a similar type. If the call is to a:

• - Fortran subroutine
• - Fortran CHARACTER function
• - Fortran COMPLEX function

then call it from C/C++ as a function that returns void. The exception is when a Fortran subroutine has alternate returns. If this is the case, call this subroutine from a function returning int whose value is the value of the integer expression specified in the alternate RETURN statement.

2.3.2 Fortran Runtime Libraries

For applications with mixed Fortran, C, or C++ code, you have the option of invoking x86 Open64 with opencc or openCC, instead of openf90 or openf95. If you do, you should always initialize the Fortran runtime libraries. Although standard Fortran I/O and most intrinsic functions will work without this initialization, the library is needed for runtime error messages, automatic stack sizing, and the intrinsics dealing with the command line arguments. The following example shows how to initialize the Fortran runtime libraries in mixed-code applications:

Example:

A large application that mixes Fortran code with code written in C or C++ and the main entry point to the application is from C or C++.

1. Optional - use opencc or openCC to link the application.
2. Manually add the Fortran runtime libraries to the link line as follows:
3. To link object files that were generated with opencc or openCC include the option ‘-lstdc++’.

 $ opencc -o exe c_file.o fort_file.o -lfortran

2.3.3 Upper/Lower Case Conventions and Underscores

All Fortran symbol names are converted to lower case, whereas C and C++ are case sensitive. When you use mixed-code calling, you can either use all lower case for your C/C++ functions or use the Fortran compiler command with the option -Mupcase, so it will not convert symbol names to lower case.

openf90 appends an underscore to Fortran global names (names of functions, subroutines and common blocks) when creating linker symbols as follows:

However, opencc does not append any underscores to function names. You can match the Fortran convention by:

• - Appending an underscore ("x_") in C so that it matches the procedure name "x" in Fortran.
• - Using the -fdecorate option to provide mapping from each Fortran name onto a linker symbol.
• - Using the -fno-underscoring option. However, this option may create symbols that conflict with those in the Fortran and C runtime libraries.
• - When Fortran calls a C/C++ function, use C$PRAGMA C in the Fortran program.

2.3.4 Data Types

You must be careful to match the data type of function/subroutine parameters and return values. Problematic data types to watch out for:

• - Fortran character because it passes a pointer to the first character and appends an integer length-count argument to the end of the usual argument list.
• - Fortran Cray pointers, declared with the pointer statement, correspond to C pointers. However, Fortran 90 pointers, declared with the pointer attribute, are unique to Fortran.

Table A shows how data types can be represented between Fortran and C/C++. Table B shows how Fortran COMPLEX type can be represented in C/C++.

Table A: Fortran and C/C++ Data Type Compatibility

Table B: Fortran and C/C++ Representation of the COMPLEX Type

2.3.5 Passing Arguments and Returning Values

In Fortran, arguments are passed by reference (the address of the argument is passed, not the argument itself). In C/C++, arguments are passed by value, except for strings and arrays, which are passed by reference. The flexibility of the C/C++ language allows for ways around these differences, such as using the & and * operators in argument passing when C/C++ calls Fortran and in argument declarations when Fortran calls C/C++.

In Fortran, for strings declared as type CHARACTER, an argument for the string length is also passed to a calling function. The length argument is passed by value, not by reference. Open64 places the length argument(s) at the end of the parameter list, following the other formal arguments.

2.3.5.1 Passing by Value (%VAL)

When passing parameters from a Fortran subprogram to a C/C++ function, you can use the %VAL() intrinsic function to pass an argument by value. The following example shows a call passing the integer i and the logical bvar by value.

integer i
logical*1 bool
call call_c_by_val (%VAL(i), %VAL(bool))

2.3.5.2 Character Return Values

When a Fortran function returns a character, you need to add the following two arguments at the beginning of the C/C++ calling function’s argument list:

• - Address of the return character or characters
• - Length of the return character

For example:

! Function returns a character
CHARACTER*(*) FUNCTION CHARFUNC(C1, I)
CHARACTER*(*) C
INTEGER I
END

The following C code sample shows where parameters tmp and 10 are supplied by the caller:

/* C declaration of Fortran function */
extern void charfunc_();
char return_array[5];
char ch[4];
int i;
charfunc_(return_array, 5, ch, &i, 4);

For a character value of constant length, for example:

CHARACTER*4 FUNCTION CHARFUNC()

you must still add the parameter representing the length, but it is not used. The value of the character function is not automatically NULL-terminated.

2.3.5.3 Complex Return Values

When a Fortran function returns a complex value, you need to add the following argument at the beginning of the C/C++ calling function’s argument list:

• - Address of the complex return value

The following example shows a Fortran function returning a complex value:

Fortran code sample:

COMPLEX FUNCTION FUNC(C, I)
 . . . 
END

The following C code sample shows where parameters cplx is supplied by the caller:

extern void func_();
typedef struct {float r, i;} complex;
complex c;
int i;
func_(&c, &i);

2.3.5.4 Arrays and Structures

C/C++ arrays and Fortran arrays use different default initial array index values: C/C++ arrays start at 0 and Fortran arrays start at 1. You need to adjust your array comparisons accordingly.

C/C++ and Fortran arrays also use different storage methods. Fortran arrays are placed in memory in column-major order and C/C++ arrays use row-major order.

To make a Fortran 90 structure use the same layout as a C structure, try using the sequence keyword, although this may not work in every case. For arrays, limit the interface to the types of arrays provided in Fortran 77 because Fortran 90 introduced data structure information that C cannot understand. For example, an argument "a (5, 6)" or "a (n)" or "a (1:* )" (where n is a dummy argument) passes a simple pointer that corresponds to a C array. However, argument "a (:,: )" or an allocatable array or a Fortran 90 pointer array does not correspond to anything in C.

2.3.5.5 Fortran Named Common Blocks

Fortran named common blocks can be represented in C/C++ by a structure whose members correspond to the members of the common block. You must add an underscore to the name of the structure in C/C++. The following example shows the Fortran common block, C equivalent and C++ equivalent:

Fortran common block:

INTEGER I
COMPLEX C
DOUBLE PRECISION D
COMMON /COMMONBLOCK/ i, c, d

C equivalent:

extern struct {
  int i;
  struct {float r, i;} c;
  double d;
} commonblock_;

C++ equivalent:

/* extern "C" is not required for global or external data */

extern "C" struct {                 
  int i;
  struct {float r, i;} c;
  double d;
} commonblock_;

Accessing Common Blocks from C

Variables in Fortran 90 modules are grouped into common blocks. One block is for initialized data and the other block is for uninitialized data. You may use ‘-fdecorate’ to access these common blocks from C, as shown in the following example:

Fortran Source Code (fprogram.f90):

module varmodule
  public
   integer :: var1
   double precision :: var2
   integer :: var3 = 11
   double precision :: var4 = 17.8
end module varmodule

program prog
  use varmodule
  var1 = 7
  var2 = 20.5
  call cfunction ()
end program prog

C Source Code (cprogram.c):

#include <stdio.h>
extern struct {
   int var1;
   double var2;
   } module_data;

extern struct {
   int var3;
   double var4;
   } module_data_initialized;

void cfunction ()
{
   printf ("%d %g\n", module_data.var1,
   module_data.var2); 
   printf ("%d %g\n", module_data_initialized.var3,
   module_data_initialized.var4);
}

$ cat dfile
.data_init.in.varmodule module_data_initialized
.data.in.varmodule.in.varmodule module_data
cfunction cfunction

Use the following command to compile and execute:

$openf90 -fdecorate dfile fprogram.f90 cprogram.c
fprogram.f90:
cprogram.c:

$ ./a.out
11 17.8
7 20.5

2.3.6 Calls Between C and Fortran

The following example shows calls between C and Fortran.

C Source Code (c_code.c):

#include <stdio.h>
#include <alloca.h>
#include <string.h>
    
extern void function_(char *str, int *i, float *f, int str_len);

/* Calling Fortran from C */ 
void call_fortran()
{
   char *str = "Hello from call_fortran";
   int i = 221;
   float f = 8.1;
   function_(str, &i, &f, strlen(str));      
}

/* Called from Fortran, passing arguments by reference */
void by_reference__(float *f, int *i,
        char *str1, int *bool, char *str2, int str1_len, int str2_len)
{

 /* A Fortran string has no null terminator, so make a local copy
  * and add a null character at the end. */
 
    printf("Arguments passed by reference\n");
    char *str1_copy = memcpy(alloca(str1_len + 1), str1, str1_len);
    char *str2_copy = memcpy(alloca(str2_len + 1), str2, str2_len);
    str1_copy[ str1_len] = str2_copy[ str2_len] = '\0';
    
    printf("float = %.1f, int = %d, bool = %d, " 
            "str1_len = %d, str2_len = %d\n",
            *f, *i, *bool, str1_len, str2_len);
    printf ("str1 = '%s', str2 = '%s'\n", str1, str2);
 
fflush(stdout);          /* Flush output before switching languages */
call_fortran ();
}

/* Called from Fortran, passing arguments by value */

int by_value__(float f, int i) 
{
    printf("Arguments passed by value\n");
    printf("float = %.1f, int = %d\n", f, i);
    fflush(stdout);
    return 4; /* true */
} 

Fortran Source Code (f_code.f90):

program f_program
  implicit none

  interface
   subroutine by_reference(float, int, string1, bool, string2)
     real float
     integer int
     character* (*) string1, string2
     logical bool
    end subroutine by_reference

    logical function by_value(f, i)
          real f
          integer i
    end function by_value
  end interface

    logical l
    pointer (pusr, usr)
    character*32 usr
    ! Use decorate.txt to create a dummy mapping for C library calls
    ! else the compiler will complain about undefine reference to getlogin_
    integer*8 getlogin_dummy
    external getlogin_dummy
    intrinsic char

    ! Call a C function passing arguments by reference.
    call by_reference(6.2, 19, 'hello', .false., 'from f_program')

    ! Call a C function passing arguments by value.
    l = by_value( %val(12.9), %val(3) )
    write(6 , "(a,i)") "logical value returned = ", l

    ! "getlogin" is a libc function that returns "char*".
    ! When a C function returns a pointer, you must use a Cray pointer
    ! to receive the address and examine the data at that address,
    pusr = getlogin_dummy()
    write(6, "(3a)") "'", usr(1:index(usr, char(0)) - 1), "'"
end program f_program

! Called from C
subroutine function(str, i, f)
    implicit none
    character* (*) str
    integer i
    real f
    write(6, "(3a,i5,f5.1)") "'", str, "'", i, f
end subroutine function

This is the third file (decorate.txt):

getlogin_dummy getlogin

Compile and execute the three files (c_code.c, f_code.f90, and decorate.txt) with this command:

$ openf90 -Wall -fdecorate decorate.txt f_code.f90 c_code.c
$ ./a.out
Arguments passed by reference
float = 6.2, int = 19, bool = 0, str1_len = 5, str2_len = 14
str1 = 'hello', str2 = 'from f_program'
'Hello from call_fortran'  221  8.1
Arguments passed by value
float = 12.9, int = 3
logical value returned = 4
'john'

3. x86 Open64 Command Options

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.

3.1 Option Summary

Here is a summary of all the options, grouped by type. Explanations are in the following sections.

Overall Options

See Options Controlling the Kind of Output.

-c -S -E -o file -help -help:string -keep -LIST: -LIST:all_options -LIST:notes -LIST:options -LIST:symbols -r -show -show-defaults -show0 -showt -dumpversion -v -version -###

Directory Options

See Options for Directory Search.

-Idir -iquotedir -isystemdir -Ldir -nostdinc -isysrootdir

C/C++ Language Options

See Options Controlling C/C++ Dialect.

-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 -std=standard -traditional

C++ Language Options

See Options Controlling C++ Dialect.

-fabi-version=N -f[no-]check-new -f[no-exceptions] -fno-emit-exceptions -f[no-]gnu-exceptions -f[no-]rtti -fuse-cxa-atexit

Fortran Language Options

See Options to Control Language Features.

-ansi -auto-use module_name -byteswapio -colN -convert conversion -d-lines -default64 -exten-source -noextend-source -nog77mangle -pad-char-literals -rreal_spec -uname

Language Feature Options

See Options to Control Language Features.

-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

Language Independent Options

See Options which are Language Independent.

-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

Optimization Options

See Options that Control Optimization.

Options that Control Feedback Directed Optimizations

-fb-create -fb-opt -fb-phase -finstrument-functions

Options that Control Global Optimizations

-apo -mso -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 -fp-accuracy -[no-]ftz -f[no-]unsafe-math-optimizations -m87-precision -noexpopt -openmp -mp -chunk -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:bias_calls_in_loops -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:pf -LNO:prefetch -LNO:prefetch_ahead -LNO:prefetch_manual

Preprocessor Options

See Options Controlling the Preprocessor.

-A predicate -A -predicate -C -cpp -dD -DI -dM -dN -Dname -Dvar -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

Assembler Option

See Passing Options to the Assembler.

-fno-asm -Wa,option

Linker and Library Options

See Options for Linking.

-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

Code Generation Options

See Options for Code Generation Conventions.

-CG:cflow -CG:cmp_peep -CG:compute_to -CG:cse_regs -CG:divrem_opt -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:strcmp_expand -CG:unroll_fb_req -CG:use_prefetchnta -CG:use_test -GRA:home -GRA:optimize_boundary -GRA:prioritize_by_density -GRA:unspill

Target Options

See Specifying Target Environment and Machine.

-TENV:frame_pointer -TENV:simd_amask -TENV:simd_dmask -TENV:simd_fmask -TENV:simd_imask -Tenv:simd_omask -TENV:simd_pmask -TENV:simd_umask -TENV:simd_zmask -TENV:X

Machine Dependent Options

See Hardware Models and Configurations. i386 and x86-64 Options

-march -mtune -mcpu -m[no-]sse -m[no-]sse2 -m[no-]sse3 -m[no-]sse4a -m[no-]3dnow -m32 -m64 -mcmodel

Diagnostic Options

See Options to Control Diagnostic.

-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

Debugging Options

See Options for Debugging Your Program.

-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

Warning Options

See Options to Request or Suppress Warnings.

-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:

Code Generation

-CLIST:

C Listing

-FLIST:

Fortran Listing

-GRA:

Global Register Allocator

-HUGEPAGE:

Huge Pages

-INLINE:

Subprogram Inlining

-IPA:

Interprocedural Analyzer

-LANG:

Language

-LIST:

Listing

- LNO:

Loop Nest Optimizer

-OPT:

General Optimizer

-TENV:

Target Environment

-WOPT:

Global Optimizer Modifier

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:

• - either use colons to separate each suboption
• - or specify multiple options on the command line.

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:

• ‘-INLINE’ is equivalent to ‘-inline’
• ‘-IPA’ is equivalent to ‘-ipa’
• ‘ -clist’ is equivalent to ‘-CLIST:=ON’.
• ‘-flist’ is equivalent to enabling all the ‘-FLIST’ options.
• ‘-HUGEPAGE’ is equivalent to ‘-HUGEPAGE:heap=ON’.

3.2 Options Controlling the Kind of Output

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:

file.c

C source code which must be preprocessed.

file.cc

file.cxx

file.cpp

file.C

C++ source code which must be preprocessed. Note that in ‘.cxx’, the last two letters must both be literally ‘x’. Likewise, ‘.C’ refers to a literal capital C.

file.i

C source code which should not be preprocessed. Note to preserve a file.i invoke the compiler with the ‘-E’ command option.

file.ii

C++ source code which should not be preprocessed.

file.h

C/C++ header file to be turned into a precompiled header.

file.hh

file.H

C++ header file to be turned into a precompiled header.

file.f

Fixed format Fortran source code which should not be preprocessed.

file.f90

file.f95

Freeform Fortran source code which should not be preprocessed.

file.F

Fixed format Fortran source code which must be preprocessed (with the traditional preprocessor).

file.F90

file.F95

Freeform Fortran source code which must be preprocessed (with the traditional preprocessor).

file.s

Assembler code. Note to preserve a file.s invoke the compiler with the ‘-S’ command option.

file.S

Assembler code which must be preprocessed.

file.o

other

An object file to be fed directly into linking. Any file name with no recognized suffix is treated this way.

file.a

A static library of object files

file.so

A library of shared object files

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.

-c

Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.

By 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.

-S

Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input file specified.

By 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.

-E

Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code with line directives, which is sent to the standard output. Use ‘-P’ to suppress line directives.

Input files which don’t require preprocessing are ignored. The‘-E’ option nullifies the ‘-nocpp’ option.

-o file

Place output in file file. This applies regardless to whatever sort of output is being produced, whether it be an executable file, an object file, an assembler file or preprocessed C code.

If ‘-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.

-help

-help:string

Print (on the standard output) a description of the command line options understood by opencc, openCC, and open95.

If ‘-help:’ is specified a description of the command line options that contain a given string is printed.

-keep

Instructs the compiler to write all intermediate compilation files. Files written after final compilation are:

• - the compiler generated preprocessed source code file, ‘filename.i’
• - the compiler generated assembly language file, ‘filename.s’

Note 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

The ‘-LIST:’ option group instructs the compiler to emit information which gets written to a listing file with the suffix ‘.lst’. The options in this group are:

-LIST:=ON|OFF

Instructs the compiler to write the list file. The emitted data to the listing file includes a list of specified options. The default is ‘-LIST:=ON’ if any ‘-LIST:question=answer’ is specified, otherwise the default is ‘-LIST:=OFF’.

-LIST:all_options=ON|OFF

Instructs the compiler to emit a list of supported options. The default is ‘-LIST:all_options=OFF’.

-LIST:notes=ON|OFF

Specifying ‘LIST:notes=OFF’ instructs the compiler not to insert a list of comments within the assembly listing that describes various actions taken by the compiler (e.g., software pipelining). Note enabling the generation of the assembly listing is a prerequisite to this option (e.g., by specifying ‘-S’). The default is ‘-LIST:notes=ON’.

-LIST:options=ON|OFF

Instructs the compiler to list the command-line options directly or indirectly modified as a side effect of other options. The default is ‘-LIST:options=OFF’.

-LIST:symbols=ON|OFF

Instructs the compiler to list information regarding the symbols (i.e. variables) managed by the compiler. The default is ‘-LIST:symbols=OFF’.

-r

Instructs the compiler to generate a relocatable object file (‘.o’) and then stop.

-show

Print the compilation phases as they execute with appropriate arguments and input/output files.

-show-defaults

Print (on the standard output) a description of target specific command line options for each tool. Also prints the options in the compiler.defaults file.

For C/C++ ‘-show-defaults’ will also print the compatible gcc version.

-show0

Print (on the standard output) the compilation phases without invoking the compiler.

-showt

Print (on the standard output) the time required by each compilation phase.

-dumpversion

Print the compiler version (for example, ‘3.0’)—and don’t do anything else.

-v

Print (on the standard output) the compiler driver, preprocessor, compiler proper, and the commands specified to run on the compilation phases.

-version

Print (on the standard output) the version number of the invoked compiler.

-###

Like ‘-v’ except the commands are not executed and all command arguments are quoted. This is useful for shell scripts to capture the driver-generated command lines.

3.3 Options for Directory Search

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 dir

Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use ‘-isystem’ for that). If you use more than one ‘-I’ option, the directories are scanned in left-to-right order; the standard system directories come after.

The ‘-I’ is used for the following types of files:

• - File names that do not begin with a slash (/) character and are located on the INCLUDE statement of the Fortran source programs.
• - File names that do not begin with a slash (/) character and are located in the #include statement of a preprocessing directives.
• - Files specified by Fortran 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:

• - first, in the directory that contains the input source file
• - second, in the directories specified by option ‘Idir’
• - third, in the standard ‘/usr/include/’ directory.

-iquote dir

Add the directory dir to the head of the list of directories to be searched for header files only for the case of ‘#include "file"’; they are not searched for ‘#include <file>’, otherwise just like ‘-I’.

-isystem dir

Search dir for header files, after all directories specified by ‘-I’ but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories.

-L dir

Add directory dir to the list of directories to be searched for ‘-l’. See ‘-llibrary’. Note for XPG4 the order of searching for libraries named in ‘-l’ is to look in the specified directory, dir, before looking in the default directory. Multiple instances of ‘-L’ can be specified and are searched in the specified order left-to-right.

-nostdinc

Do not search the standard system directories for header files. Only the directories you have specified with ‘-I’ options (and the directory of the current file, if appropriate) are searched.

-isysroot dir

Use dir as the logical root directory for header files. For example, the compiler normally searches for headers in '/usr/include'. With this option it searches 'dir/usr/include' instead.

3.4 Compiling C++ Programs

C++ 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++.

3.5 Options Controlling C/C++ Dialect

The following options control the dialect of C (or languages derived from C, such as C++) that the compiler accepts:

-ansi

In C mode, this is equivalent to ‘-std=c89’. In C++ mode, it is equivalent to ‘-std=c++98’.

This 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-keywords

‘-fgnu-keywords’ instructs the compiler to recognize typeof 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-extensions

Accept some non-standard constructs used in Microsoft header files. This option disables pedantic warnings about constructs used in MFC, such as implicit int and getting a pointer to member function via non-standard syntax.

Some cases of unnamed fields in structures and unions are only accepted with this option.

-fno-builtin

Don’t recognize built-in functions that do not begin with ‘__builtin_’ as prefix. See Other built-in functions provided by x86 Open64 for details of the functions affected, including those which are not built-in functions when ‘-ansi’ or ‘-std’ options for strict ISO C conformance are used because they do not have an ISO standard meaning. Note the x86 Open64 C/C++ compiler does not support many of the __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-common

In C, allocate even uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without extern) 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

Instruct the compiler to attach a prefix to all function names.

-fpack-struct[=n]

Without a value specified, pack all structure members together without holes. When a value is specified (which must be a small power of two), pack structure members according to this value, representing the maximum alignment (i.e. objects with default alignment requirements larger than this will be potentially unaligned at the next fitting location).

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-double

Use the same size for double 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-enums

Allocate to an enum 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-wchar

Override the underlying type for ‘wchar_t’ to be ‘short unsigned int’ instead of the default for the target.

Warning: 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-bitfields

These options control whether a bit-field is signed or unsigned, when the declaration does not use either signed 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-char

Let the type char 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-aliasing

Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned 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’.

-std=standard

Determine the language standard. See Language Standards Supported by x86 Open64, for details of these standard versions. This option is currently only supported when compiling C or C++.

The 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 specifying 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 specifying 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

‘c89’

‘iso9899:1990’

Support all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as ‘-ansi’ for C code.

‘iso9899:199409’

ISO C90 as modified in amendment 1.

‘c99’

‘c9x’

‘iso9899:1999’

‘iso9899:199x’

Support all ISO C99 programs.

‘gnu89’

GNU dialect of ISO C90 (including some C99 features). This is the default for C code.

‘gnu99’

‘gnu9x’

GNU dialect of ISO C99. The name ‘gnu9x’ is deprecated.

‘c++98’

The 1998 ISO C++ standard plus amendments. Same as ‘-ansi’ for C++ code.

‘gnu++98’

GNU dialect of ‘-std=c++98’.

The default is ‘-std=gnu89’ for C code and ‘-std=gnu++98’ for C++ code

-traditional

Formerly, these options caused the compiler to attempt to emulate a pre-standard C compiler. They are now only supported with the ‘-E’ switch. The preprocessor continues to support a pre-standard mode. See the GNU CPP manual for details.

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)

Use version N of the C++ ABI. Version 2 is the version of the C++ ABI that first appeared in g++ 3.4. Version 1 is the version of the C++ ABI that first appeared in g++ 3.2. Version 0 will always be the version that conforms most closely to the C++ ABI specification. Therefore, the ABI obtained using version 0 will change as ABI bugs are fixed.

The default is ‘-fabi-version=2’ or version 2.

-fcheck-new (C++ Only)

-fno-check-new (C++ Only)

Check that the pointer returned by 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 signaled 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.

-fno-emit-exceptions (C++ Only)

Enables exception handling, but does not generate code needed to raise/catch exceptions. This option allows the compiler to accept exceptions as part of the C++ dialect but in effect asserts that these exceptions will not actually be raised at runtime.

-fexceptions (C++ Only)

-fno-exceptions (C++ Only)

-fgnu-exceptions (C++ Only)

-fno-gnu-exceptions (C++ Only)

Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies the compiler will generate frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, Open64 will enable it by default for languages like C++ which normally require exception handling, and disable it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don’t use exception handling.

-frtti (C++ Only)

-fno-rtti (C++ Only)

When specifying ‘-frtti’ the compiler will emit runtime type information. ‘-fno-rtti’ disables generating information about every class with virtual functions for use by the C++ runtime type identification features (‘dynamic_cast’ and ‘typeid’). If you don’t use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. The ‘dynamic_cast’ operator can still be used for casts that do not require runtime type information, i.e. casts to void * or to unambiguous base classes.

-fuse-cxa-atexit (C++ Only)

Register destructors for objects with static storage duration with the __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.

3.6 Options Controlling Fortran Dialect

The following options control the dialect of Fortran that the compiler accepts:

-ansi

Instructs the compiler to emit messages regarding constructs that violate Fortran syntax rules and constraints. Including messages about obsolescent and deleted features. This option disables all nonstandard intrinsic functions and subroutines. Note specifying ‘-ansi’ implies option ‘-ffortran2003’and when used concurrently with ‘-fullwarn’ causes all messages to be generated (i.e. regardless of level).

-auto-use module_name[,module_name]...

Instruct the compiler to act as if a USE module_name statement was entered in the Fortran source code for each module_name. The compiler inserts USE statements in every program unit and interface body in the compiled source code. For example,

openf95 -auto-use mpi_interface

or

openf95 -auto-use shmem_interface

Note in some situations using ‘-auto-use’ can increase compiler time.

-byteswapio

‘-byteswapio’ swaps bytes during I/O so that unformatted files on a little-endian processor are read and written in big-endian format (or vice versa.) Use the option when compiling the Fortran main program. Note the ‘-byteswapio’ option affects record headers as well as data in sequential unformatted files. Setting the environment variable FILENV during program execution will supersede the compiled-in code generated option in favor of the choice established by the assign command.

-colN

Specifies the line width for fixed-format source lines. Set N to 72, 80, or 120.

-convert conversion

‘-convert conversion’ controls the swapping of bytes during I/O so that unformatted files on a little-endian processor are read and written in big-endian format (or vice versa). Use the option when compiling the Fortran main program. Note the ‘-byteswapio’ option affects record headers as well as data in sequential unformatted files. Setting the environment variable FILENV during program execution will supersede the compiled-in code generated option in favor of the choice established by the command assign. The option supports three arguments

native

No conversion

little_endian

Files are little-endian

big_endian

Files are big-endian

The default is ‘-convert native’.

-d-lines

Instruct the compiler to insert a D in column 1 of compiled lines.

-default64

The compiler sets the sizes of default integer, real, logical, and double precision objects. ‘-default64’ causes the following options to go into effect: ‘-r8’ and ‘-i8’. Note calling a function in a specialized library requires that its 32-bit (or 64-bit) entry point be specified when 32-bit (or 64-bit) data is being used.

-extend-source

-noextend-source

The line length for fixed-format source files are set to 132 character-per-line. The default for fixed-format lines are 72 characters-per-line. See ‘-colN’, for more information on controlling line length.

-nog77mangle

Fortran symbol names are modified by the compiler by appending an underscore to the symbol name, e.g., symbol name foo 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

Extend the length (i.e., by padding with blanks) of all character literal constants to the size of the default integer type and that are passed as actual arguments.

-rreal_spec

Specifies the default KIND specification for real values.

-r4

Use REAL(KIND=4) for real variables and COMPLEX(KIND=4) for complex variables.

-r8

Use REAL(KIND=8) for real variables and COMPLEX(KIND=8) for complex variables.

The default is ‘-r4’.

-uname

Instructs the compiler to assign the default type of the variable, name, to be undefined rather then using default Fortran 90 rules.

3.7 Options to Control Language Features

The options described below can be used to control the features of the C/C++ or Fortran language.

-LANG:question=answer

Options in the ‘-LANG:’ group can be used to control the set of features that are supported. For example, to compile code that does not conform with the Standard in one way or another. Note it may not always be possible, however, to link together object files, some of which have been compiled with a feature enabled and others with it disabled.

-LANG:copyinout=ON|OFF

If an array section is passed as an argument in a call, the compiler is instructed to copy the array section into a temporary array that will be passed as the argument in the call. ‘-LANG:copyinout’ optimizes the accessing of array arguments by improving argument locality. Note the flag helps regulate the aggressiveness of this optimization and is mainly suited to Fortran code. When specifying global optimization ‘-O2’ or higher ‘-LANG:copyinout=ON’. The default is ‘-LANG:copyinout=OFF’.

-LANG:formal_deref_unsafe=ON|OFF (Fortran Only)

The compiler is instructed that it is unsafe to attempt any optimizations regarding the dereference of a formal parameter. The default is ‘-LANG:formal_deref_unsafe=OFF’.

-LANG:global_asm=ON|OFF

The compiler’s assembler is instructed to allocate objects to sections if the program includes a file-scope assembly statement. ‘-LANG:global_asm=ON’ causes some alignment optimizations to be suppressed allowing the allocations performed by the compiler to be compatible with the allocations in the assembly statement. The default is ‘-LANG:global_asm=OFF’.

-LANG:heap_allocation_threshold=size

Specifies the threshold when determining if to allocate an automatic array or compiler temporary on the heap rather than on the stack. Parameter size is in bytes and sets the threshold. Setting size to -1 implies all objects are placed on the stack. Setting size to 0 implies all objects are placed on the heap. The default is ‘-LANG:heap_allocation_threshold=-1’ for maximum performance.

-LANG:IEEE_minus_zero=ON|OFF (Fortran only)

Instructs the compiler to acknowledge negative floating-point zeroes (i.e. -0.0). ‘-LANG:IEEE_minus_zero=OFF’ disables the intrinsic function 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)

When a procedure accesses a standard IEEE intrinsic module with a 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 ON a statically allocated local variable can be referenced or modified by a recursive procedure call. The statically allocated local variable must be stored in memory before making a call and reloaded afterward.

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)

Instructs the compiler to handle constant parameter as either read-only or read-write. If the compiler is instructed to handle a constant parameter as read-write, then extra code must be generated to accommodate the possibility of the constant parameter being changed in the called function. Note when turned OFF the compiler generates more efficient code but segmentation faults will occur when writing to the constant parameter. The default is ‘-LANG:rw_const=OFF’.

-LANG:short_circuit_conditionals=ON|OFF (Fortran Only)

The compiler is instructed to manage the logical .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’.

3.8 Options which are Language Independent

-alignN

Arranges for the data to be aligned on common blocks to a specified boundary. Selections for ‘-alignN’ are as follows:

-align32

Align common blocks of data on 32-bit boundaries.

-align64

Align common blocks of data on 64-bit boundaries.

Objects 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:

• - object sizes less than 64-bits but at least 32-bits are aligned on 32-bit boundaries.
• - object sizes less than 32-bits but at least 16-bits are aligned on 16-bit boundaries.
• - object sizes less than 16-bits are aligned on 8-bit boundaries.

-backslash

Instructs the compiler to consider a backslash as a normal character instead of an escape character. Note specifying ‘-backslash’ instructs the compiler not to pass the code through the preprocessor.

-funwind-tables

-fno-unwind-tables

Similar to ‘-fexceptions’, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. The default is ‘-fno-unwind-tables’.

-finhibit-size-directive

Don’t output a .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.

-fpic

Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of the compiler; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that ‘-fpic’ does not work; in that case, recompile with ‘-fPIC’ instead.

When this flag is set, the macros __pic__ and __PIC__ are defined to 1.

-fPIC

If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table.

Position-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

Instruct the compiler to disregard the #ident directive.

-HP:question=answer[,argument=N,...]

-HUGEPAGE:question=answer[,argument=N,...]

-HP

-HUGEPAGE

The compiler supports command line options to use 2 MByte huge pages for heap and “bdt”, where “bdt” stands for bss, data and text segments. This option group is operating system (OS) dependent, refer to the release notes for more information on which OS versions are supported.

A 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

The compiler is instructed to use huge pages for bss, data, and text segments (a.k.a, bdt). The ‘-HUGEPAGE:bdt’ option is not compatible with the ‘-pg’ option. A mixed usage of huge pages and small pages is also currently not supported for option ‘-HUGEPAGE:bdt=size’ (i.e. bss, data, and text). The sub-option can be set to:

2m

Instructs the compiler to use 2 MByte huge pages for bss, data, and text segments.

-HP:heap=size[,argument=N,...]

-HUGEPAGE:heap=size[,argument=N,...]

The compiler is instructed to use huge pages for the heap segment. A mixed usage of huge pages and small pages is currently supported for ‘-HUGEPAGE:heap=size’. The sub-option can be set to:

2m

Instructs the compiler to use 2 MByte huge pages for bss, data, and text segments.

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

‘-HUGEPAGE’ and ‘-HP’ are abbreviated forms for sub-options ‘-HUGEPAGE:heap=2m’ and ‘-HP:heap=2m’, respectively. For example:

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

The ‘-ignore-suffix’ flag instructs the compiler to ignore the suffix of the input source files. The language of the source file is designated by the compiler driver. Specifying ‘-ignore-suffix’ forces the compiler driver opencc to invoke the C compiler, openCC to invoke the C++ compiler, and openf95 to invoke the Fortran compiler. By default the language of the source file is determined by the suffixes of the file (i.e. ‘.c’, ‘.cpp’, ‘.C’, ‘.cxx’, ‘.f’, ‘.f90’, and ‘.s’).

-opencc

-no-opencc

‘-opencc’ instructs the compiler to define the __OPEN64__ macro and other predefined preprocessor macros. ‘-no-opencc’ instructs the compiler to disable these macros.

-nobool

Instruct the compiler to not allow boolean keywords.

-U name

Instructs the compiler to remove any initial definition of name.

3.9 Options That Control Optimization

These 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.

3.9.1 Options that Control Feedback Directed Optimizations

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

Instructs the compiler to generate an instrumented executable program from the source code under development. The instrumented executable produces feedback data files at runtime using an example dataset. filename specifies the name of the feedback data file generated by the instrumented executable.

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

Instructs the compiler to perform a feedback directed compilation using the instrumented feedback data produced by the ‘-fb-create’ option.

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

Specifies the compilation phase when the collection of instrumentation data is to be performed. The values for option ‘-fb-phase’ must be in the range of 0 to 4 and is used in conjunction with ‘-fb-create’. Note the value 0 indicates the initial phase, which is at the output of the preprocessor (i.e. after the front-end processing). The default is ‘-fb-phase=0’.

-finstrument-functions

Generates instrumentation calls for entry and exit to functions. Just after function entry and just before function exit, the following profiling functions will be called with the address of the current function and its call site. (On some platforms, __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’.

3.9.2 Options that Control Global Optimizations

-apo

Instructs the compiler to automatically transform sequential code into parallel code. The compiler will only transform blocks of code that will demonstrate a speed-up to the runtime (i.e. execute faster) on a multiprocessor target.

-mso

Instructs the compiler to perform aggressive optimizations that are likely to improve the scalability of an application running on a system with multi-core processors. In particular, these optimizations may target machine resources that are shared among the multiple cores of a processor, e.g. memory bandwidth, shared L3 cache, etc.

-O0|1|2|3|s

Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.

-O0

No optimizations are performed.

-O1

Perform minimal local optimizations on sections of straight-line code (basic blocks) only. Examples of such optimizations are instruction scheduling and some peephole optimizations. These optimizations do not usually have any noticeable impact on compilation time.

-O2

Perform extensive global optimizations. Examples of such optimizations are control flow optimizations, partial redundancy elimination and strength reduction. These optimizations can very often reduce the execution time of the compiled program significantly, but they may do so at the expense of increased compilation time. This is the default level of optimization.

-O3

Perform all the optimizations at the ‘-O2’ level as well as many more aggressive optimizations. Examples of such aggressive optimizations are loop nest optimizations and generation of prefetch instructions. Although these more aggressive optimizations can significantly sped up the run time execution of the compiled program, in rare cases they may not be profitable and may instead lead to a slow down. Also, some of these more aggressive optimizations may affect the accuracy of some floating point computations.

-Os

Optimize for size. ‘-Os’ enables all ‘-O2’ optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.

If 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

Uses a selection of optimizations in order to maximize performance. Specifying ‘-Ofast’ is equivalent to

-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

This group of options controls the effect the global optimizer has on the program. ‘-WOPT:’ only influences global optimizations specified by ‘-O2’ or above.

-WOPT:aggstr=N

Option ‘-WOPT:aggstr’ regulates the aggressiveness of the compiler’s scalar optimizer when performing strength reduction optimizations. Strength reduction is the substitution of induction expressions within a loop with temporaries that are incremented together with the loop variable. The value N specifies the maximum number of induction expressions being replaced. Select positive integers only for variable N. Setting N=0 tells the scalar optimizer to use strength reduction for non-trivial induction expressions. Note specifying very aggressive strength reductions may prompt additional temporaries increasing register pressure and resulting in excessive register spills that decrease performance. The default is ‘-WOPT:aggstr=11’.

-WOPT:const_pre=ON|OFF

‘-WOPT:const_pre=ON’ instructs the compiler to perform the loading of registers using placement optimizations. The default is ‘-WOPT:const_pre=ON’.

-WOPT:if_conv=0|1|2

‘-WOPT:if_conv’ instructs the compiler to transform simple IF statements to conditional move instructions. ‘-WOPT:if_conv’ has three settings:

0

Disables this optimization

1

Specifies conservative IF statement transformations. The context surrounding the IF statement is used in the transformation decision.

2

Use aggressive 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:ivar_pre=ON’ instructs the compiler to use partial redundancy elimination of indirect loads in the program. The default is ‘-WOPT:ivar_pre=ON’.

-WOPT:mem_opnds=ON|OFF

The compiler’s scalar optimizer is instructed to use automated reasoning to protect all memory operands of arithmetic operations. The process attempts to incorporate memory loads as part of the operands of arithmetic operations (e.g., the compiler tries to combine a memory load and an arithmetic instruction into one instruction). The default is ‘WOPT:mem_opnds=OFF’.

-WOPT:retype_expr=ON|OFF

Whenever possible the compiler calculate 64-bit addresses using 32-bit arithmetic. The default is ‘-WOPT:retype_expr=OFF’.

-WOPT:unroll=0|1|2

Specifying ‘WOPT:unroll’ helps regulate the compiler’s scalar optimizer when unrolling of innermost loops. The available settings are:

0

Innermost loop unrolling is suppressed.

1

Instructs the compiler’s scalar optimizer to unroll the innermost loops which contain IF statements. Selecting this setting complements the loop unrolling performed in the code generator.

2

Instructs the compiler’s scalar optimizer to unroll the innermost loops which contain straight line code plus the loops containing 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|2

The compiler attempts to identify expressions which compute identical runtime values. Then proceeds to adjust the code to avoid recomputing the values. Setting ‘-WOPT:val’ tells the global optimizer the number of times the value-numbering optimization should be performed. The default is ‘-WOPT:val=1’.

3.9.3 Options that Control General Optimizations

The 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.

-chunk=N

Sets the default chunk size to N. When the ‘-apo’ and ‘-mp’ options are used, loops may be parallelized with different iterations of a loop being scheduled to execute on different threads. The chunk size is the number of consecutive iterations of a parallel loop assigned to a thread each time work is scheduled for a thread. The default is the total number of iterations divided by the number of threads.

-ffast-math

-fno-fast-math

Instructs the compiler to relax ANSI/ISO or IEEE rules/specifications for math functions in order to optimize floating-point computations to improve runtime. ‘-fno-fast-math’ instructs the compiler to conform to ANSI and IEEE math rules.

This 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-store

Do not store floating-point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.

This 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-store’has no effect under ‘-msse2’, the default when specifying ‘-m32’ and ‘-m64’.

-fno-math-errno

Do not set ERRNO after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on IEEE exceptions for math error handling may want to use this flag for speed while maintaining IEEE arithmetic compatibility. Note specifying ‘-Ofast’ implies ‘-fno-math-errno’. The default is ‘-fmath-errno’.

-fp-accuracy=strict|strict-contract|relaxed|aggressive

This flag sets the accuracy level of floating point operations.

strict

Instructs the compiler to strictly adhere to value-safe optimizations to implement floating-point calculations and support floating-point exception semantics. This is the strictest floating point accuracy model. The ‘-fp-accuracy=strict’ option also sets ‘-OPT:IEEE_arith=1’ and ‘-OPT:roundoff=0’

strict-contract

Instructs the compiler to allow contractions, such as fused multiply add operations, but otherwise use value-safe optimizations to implement floating-point calculations and support floating-point exception semantics. The ‘-fp-accuracy=strict-contract’ option also sets ‘-OPT:IEEE_arith=1’ and ‘-OPT:roundoff=0’

relaxed

Instructs the compiler to allow more relaxed optimizations that have limited effect on floating-point results. The ‘-fp-accuracy=relaxed’ option also sets ‘-OPT:IEEE_arith=2’ and ‘-OPT:roundoff=1’

aggressive

Instructs the compiler to use more aggressive optimizations for floating-point calculations. These optimizations increase speed, but may alter the accuracy of floating-point calculations. The ‘-fp-accuracy=aggressive’ option also sets ‘-OPT:IEEE_arith=3’ and ‘-OPT:roundoff=2’

-ftz

-fno-ftz

Instructs the compiler to enable flushing to zero of floating point calculations that underflow into the denormal range. To enable flush to zero behavior, setup code is included in the C/C++ or Fortran main function. Hence, this option has no effect when applied to other files.

This option sets or resets both FZ and DAZ hardware control bits in the MXCSR register and affect FP operations executed by the 128-bit and 256-bit media instructions.

When the Denormals Are Zeros (DAZ) bit is set, denormal values used as inputs to floating-point instructions are treated as zero. When the Flush To Zero (FZ) bit is set, denormal results from floating point calculations are flushed to zero.

-funsafe-math-optimizations

-fno-unsafe-math-optimizations

‘-funsafe-math-optimizations’ instructs the compiler to allow optimizations for floating-point arithmetic that assume that arguments and results are valid, and may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default floating-point unit control word or other similar optimizations. ‘-fno-unsafe-math-optimizations’ instructs the compiler to conform to ANSI and IEEE math rules. The default is ‘-fno-unsafe-math-optimizations’.

-mx87-precision=32|64|80

Specifies the floating-point precision of the floating-point units calculations. The three settings available are: 32-bit, 64-bit, or 80-bit. The default is ‘-mx87-precision=80’.

-noexpopt

Instructs the compiler to not optimize exponential operations.

-openmp

-mp

Instructs the compiler to interpret OpenMP directives to explicitly parallelize specified code for multi-thread execution on shared-memory multiprocessor models. The opencc, openCC, and openf95 compilers support directives for OpenMP 2.5.

-OPT:question=answer

The ‘-OPT:’ option group controls various optimizations. The ‘-OPT:’ options supersede the defaults that are based on the main optimization level.

-OPT:alias=model

Identify which pointer aliasing model to use. The compiler will make assumptions during compilation when one or more of the following model is specified.

typed

Assumes that two pointers of different types will not point to the same location in memory (i.e. the code adheres to the ANSI/ISO C standards). Note when specifying ‘-OPT:Ofast’ turns this option ON.

restricted

Assumes that distinct pointers are pointing to distinct non-overlapping objects. This optimization is disabled by default.

disjoint

Assumes that any two pointer expressions are pointing to distinct non-overlapping objects. This optimization is disabled by default.

no_f90_pointer_alias

Assumes that any two different Fortran 90 pointers are pointing to distinct non-overlapping objects. This optimization is disabled by default.

-OPT:align_unsafe=ON|OFF

Assumes that array parameters are aligned at 128-bit boundaries and instructs the vectorizor to aggressively vectorize the code. The vectorizor then proceeds to generate 128-bit aligned load 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

Assumes each inline assembly instruction has specified memory (i.e. even if it is not available). Note this switch can be used to debug suspicious inline assembly code. The default is ‘-OPT:asm_memory=OFF’.

-OPT:bb=N

The value N limits the number of instructions a basic block can contain in the code generator’s program representation. A basic block is defined as the straight line sequence of instructions with no control flow. Note the larger the value N the greater the opportunity exists for applying optimizations at the basic block level. Compiling programs where N is large and that exhibit large basic blocks could increase compilation time. The default is ‘-OPT:bb=1300’. Select a smaller value if compilation time becomes an issue.

-OPT:cis=ON|OFF

SIN/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|4

Instructs the compiler to insert instrumentation calls into each function. Instrumentation calls are inserted following the function entry and just before the function returns. Example insertions:

void__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:

0

Do not instrument any function.

1

Do not instrument functions the GNU front-end selects for inlining.

2

Do not instrument functions marked inline in the source.

3

Do not instrument functions marked extern inline or always_inline.

4

Instrument all functions and disable deletion of extern inline functions. Specifying this value may create linking and runtime faults.

Note options ‘-finstrument-function’ and ‘-OPT:cyg_instr=3’ are equivalent, See ‘-finstrument-functions’.

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|OFF

Instruct the compiler to transform x/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|OFF

Instructs the compiler to transform code to execute under multiple threads only before or after the loop nest optimization (LNO) phase in the compilation process. When ‘-OPT:early_mp=ON’ some OpenMP programs yield better performance because LNO is allowed to generate appropriate loop transformations when working on the multi-threaded forms of loops. Note if ‘-apo’ is specified the transformation of code executing multiple threads can only take place after LNO phase. In which case the ‘-OPT:early_mp’ flag is ignored.

The default is ‘-OPT:early_mp=OFF’.

-OPT:early_intrinsics=ON|OFF

Generate calls to intrinsics which can be expanded to inline code early in the back-end compilation. The early inlining could expose short-vector forms in the expanded code leading to vectorization opportunities. The default is ‘-OPT:early_intrinsics=OFF’.

-OPT:fast_bit_intrinsics=ON|OFF (Fortran Only)

If ‘-OPT:fast_bit_intrinsics=ON’ the check for the bit count being within range for Fortran intrinsics (e.g., BTEST or ISHFT) will be turned off. The default is ‘-OPT:fast_bit_intrinsics=OFF’.

-OPT:fast_complex=ON|OFF

Specifies fast calculations for values declared to be of the type complex. 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

Transforms exponentiation by integers or halves to sequences of multiplies and square roots. This option can affect roundoff, and can make these functions produce minor discontinuities at the exponents where it applies. Note specifying ‘-O3’, ‘-Ofast’, or ‘-OPT:roundoff=1’ will enable this option. The default is ‘-OPT:fast_exp=OFF’.

-OPT:fast_io=ON|OFF (C/C++ Only)

Instruct the compiler to enable inlining of 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

Instructs the compiler to use the fast math functions tuned for the target processor. The fast math functions include log, exp, sin, cos, sincos, expf, and pow. Note ‘-OPT:fast_math=ON’ when ‘-OPT:roundoff’ is set to be equal to or greater than 2. The default is ‘-OPT:fast_math=OFF’.

-OPT:fast_nint=ON|OFF

Instructs the compiler to use hardware features to implement single-precision and double-precision NINT 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|OFF

Instructs the compiler to calculate the square root using the identity sqrt(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

Instructs the compiler to generate calls to faster versions of standard library functions. The default is ‘-OPT:fast_stdlib=ON’.

-OPT:fast_trunc=ON|OFF

Instructs the compiler to inline the single-precision and double-precision versions of the Fortran intrinsics NINT, 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

When set to ON the compiler performs transformations which reassociate or distribute a floating-point expression. Note, specifying ‘-O3’ or ‘-OPT:rounoff’ to be equal to or greater than 2, forces ‘-OPT:fold_reassociate=ON’ . The default is ‘-OPT:fold_reassociate=OFF’.

-OPT:fold_unsafe_relops=ON|OFF

Instructs the compiler to fold relational operators that will transform possible integer overflow.

Note, specifying ‘-O3’ sets ‘-OPT:fold_unsafe_relops=ON’. The default is ‘-OPT:fold_unsafe_relops=OFF’.

-OPT:fold_unsigned_relops=ON|OFF

Instructs the compiler to fold relational operators involving unsigned integers that may be simplified at compile time, which may cause fewer overflows to be seen at run time. The default is ‘-OPT:fold_unsigned_relops=ON’

-OPT:goto=ON|OFF

Transforms GOTO 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

This flag regulates the level of conformance to ANSI/IEEE 754-1985 floating point roundoff and overflow. Note ‘-OPT:IEEE_arith’ and ‘-OPT:IEEE_a’ are valid abbreviations for the option. The levels of conformance:

1

Adhere to IEEE 754 accuracy. Specifying ‘-O0’, ‘-O1’, and ‘-O2’ will set ‘-OPT:IEEE_arithmetic=1’.

2

Inexact results that do not conform to IEEE 754 may be calculated. Specifying ‘-O3’ will set ‘-OPT:IEEE_arithmetic=2’.

3

All valid mathematical transformations (possibly non-IEEE standard ones) are allowed.

-OPT:IEEE_NaN_inf=ON|OFF

Instructs the compiler to conform to ANSI/IEEE 754-1985 for all operations which produce a NaN or infinity result. Note NaN and infinity are typically handled as special cases in floating-point representations of real numbers and are defined by the IEEE 754 Standards for Binary Floating-point Arithmetic.

When 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:inline_intrinsics=OFF’ transforms all Fortran intrinsics that have a library function into a call to that function. The default is ‘-OPT:inline_intrinsics=ON’.

-OPT:keep_ext=ON|OFF

Instructs the compiler to preserve external symbolic information. The default is ‘-OPT:keep_ext=OFF’.

-OPT:malloc_algorithm=0|1|2

-OPT:malloc_alg=0|1|2

To improve runtime speed the compiler will select an optimal malloc algorithm. To enable the selected algorithm, setup code is included in the C/C++ and Fortran main function. The flag can be set to:

0

No changes are made to malloc options. No call to mallopt is made.

1

Calls mallopt with settings of M_MMAP_MAX=2 and M_TRIM_THRESHOLD=0x10000000.

2

Calls mallopt with settings of M_MMAP_MAX=2 and M_TRIM_THRESHOLD=0x40000000.

The default is ‘-OPT:malloc_algorithm=0’. The M_MMAP_MAX parameter to mallopt specifies the maximum number of chunks to allocate with mmap. The M_TRIM_THRESHOLD parameter to mallopt specifies the maximum size (in bytes) of the top-most, releasable chunk that will case sbrk system call with a negative argument in order to return memory to the system.

The ‘-OPT:malloc_algorithm’ option has no effect when the ‘-HP:heap’ option is specified.

-OPT:Ofast

Maximizes performance for a given platform using the selected optimizations. ‘-OPT:Ofast’ specifies four optimizations: ‘-OPT:ro=2’, ‘-OPT:Olimit=0’, ‘-OPT:div_split=ON’, and ‘-OPT:alias=typed’. Note the specified optimizations are ordinarily safe but floating point accuracy due to transformations may be diminished.

-OPT:Olimit=N

Controls the size of procedures to be optimized. Procedures above the specified cutoff limit, N, are not optimized. N=0 means “infinite Olimit,” which causes all procedures to be optimized with no consideration regarding compilation times. Note if ‘-OPT:Ofast’ is enabled then ‘-OPT:Olimit=0’ or when ‘-O3’ is enabled ‘-OPT:Olimit=9000’. The default is ‘-OPT:Olimit=6000’.

-OPT:pad_common=ON|OFF

Instructs the compiler to reorganize common blocks in order to optimize the cache behavior of accesses to members of the common block. To achieve the optimum, additional padding between members of blocks and/or dividing a common block into a group of blocks may be required. Note:

• - do not specify this option unless the common block definitions (i.e. including EQUIVALENCE) are consistent among all source codes making up a program.
• - do not specify ‘-OPT:pad_common=ON’ if common blocks are initialized with DATA statements
• - Specifying ‘-OPT:pad_common=ON’ implies that all source codes in the program conform to this transformation.

The default is ‘-OPT:pad_common=OFF’

-OPT:recip=ON|OFF

Instructs the compiler to use the reciprocal instruction for 1.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

Instructs the compiler to reorganize common block in order to optimize the cache behavior of accesses to members of the common block. If the compiler determines it is safe, it will proceed with the common block reorganization. Note defaults are:

-OPT:reorg_common=ON

When ‘-O3’ is specified, plus all source files which reference the common block are compiler with ‘-O3’.

_OPT:reorg_common=OFF

‘-O2’ or below is specified when compiling the file that contains the common block.

-OPT:roundoff=0|1|2|3

-OPT:ro=0|1|2|3

‘-OPT:roundoff’ specifies acceptable levels of divergence for both accuracy and overflow/underflow behavior of floating-point results relative to the source language rules. The roundoff value has a value in the range 0 to 3 and are described in the following table:

0

Do no transformations which could affect floating-point results. The is the default for optimization levels ‘-O0’, ‘-O1’, and ‘-O2’.

1

Allow all transformations which have a limited affect on floating-point results. For roundoff, limited is defined as only the last bit or two of the mantissa is affected. For overflow or underflow, limited is defined as intermediate results of the transformed calculation may overflow or underflow within a factor of two where the original expression may have overflowed or underflowed. Note that effects may be less limited when compounded by multiple transformations. This is the default when ‘-O3’ is specified.

2

Specifies transformations with extensive effects on floating-point results. For example, allow associative rearrangement (i.e. even across loop iterations) and the distribution of multiplication over addition or subtraction. Do not specify transformations known to cause:

• - cumulative roundoff errors.
• - overflow/underflow of operands in a large range of valid floating-point values.

This is the default when specifying ‘-OPT:Ofast’

3

Specify any mathematically valid transformation of floating-point expressions. For example, floating point induction variables in loops are permitted (even if known to cause cumulative roundoff errors). Also permitted are fast algorithms for complex absolute value and divide (which will overflow/underflow for operands beyond the square root of the representable extremes).

-OPT:rsqrt=0|1|2

Instructs the compiler to use the reciprocal square root instruction when calculating the square root. This transformation may vary the accuracy slightly.

0

Restrain from using the reciprocal square root instruction

1

Use the reciprocal square root instruction followed by operations that will improve the accuracy of the results.

2

Use the reciprocal square root instruction without improving the result accuracy.

Note specifying ‘-OPT:roundoff=2’ or ‘-OPT:roundoff=3’ will set ‘-OPT:rsqrt=1’. The default is ‘-OPT:rsqrt=0’.

-OPT:space=ON|OFF

Instructs the compiler to consider code size as a higher priority then execution time when performing optimization. Note ‘-Os’ sets this option to equal ON. The default is ‘-OPT:space=OFF’.

-OPT:speculate=ON|OFF

Instructs the compiler to make an effort to eliminate branches at the expense of increasing the computations. Whenever possible, the compiler transforms short-circuiting conditionals to comparable non-short-circuited structures. The default is ‘-OPT:speculate=OFF’.

-OPT:transform_to_memlib=ON|OFF

Instructs the compiler to perform loop transformations by using library function calls to memcpy or memset. The default is ‘-OPT:transform_to_memlib=ON’.

-OPT:treeheight=ON|OFF

Instructs the compiler to perform a global reassociation of expressions which reduces the tree height of the expressions. The reassociation process determines the optimum order of combining terms in a sum so as to produce loop invariant constant subcomputations or to refine common subexpressions among several essential computations. The default is ‘-OPT:treeheight=OFF’.

-OPT:unroll_analysis=ON|OFF

Instructs the compiler to disregard both ‘-OPT:unroll_times_max’ and ‘-OPT:unroll_size’. The compiler then proceeds to perform a global analysis of the loop constructs to determine the optimum loop unrolling parameters. As a result of the analysis minimal loop unrolling which reduces code size may occur, permitting a faster compilation. Note specifying ‘-OPT:unroll_analysis=ON’ negates the effects of ‘-OPT:unroll_times_max’ and ‘-OPT:unroll_size’ causing loops to be unrolled by less than the upper limit. The default is ‘-OPT:unroll_analysis=ON’.

-OPT:unroll_level=1|2

Controls the level at which the compiler will perform unrolling optimizations. When ‘-OPT:unroll_level=2’ the compiler is instructed to aggressively unroll loops in the presence of control flow. The default is ‘-OPT:unroll_level=1’.

-OPT:unroll_times_max=N

Instructs the compiler to limit the unrolling of inner loops to the value specified by N. The default is ‘-OPT:unroll_times_max=4’.

-OPT:unroll_size=N

Instructs the compiler to limit the number of instructions produced when unrolling inner loops. When N=0 the ceiling is disregarded. Note specifying ‘-O3’ sets ‘-OPT:unroll_size=128’. The default is ‘-OPT:unroll_size=40’.

-OPT:wrap_around_unsafe_opt=ON|OFF

‘-OPT:wrap_around_unsafe_opt=OFF’ instructs the compiler not to perform induction variable replacement and linear function test replacement. Both of these transformations are enabled when specifying ‘-O3’. The option is provided as a diagnostic tool. Note specifying ‘-O0’ sets ‘-OPT:wrap_around_unsafe_opt=OFF’. When ‘-OPT:wrap_around_unsafe_opt=OFF’ the performance may be degraded.

3.9.4 Options that Control Interprocedural Optimizations

Inline 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-inline-templates’ instructs the compiler to emit code for implicit instantiations of inline templates. ‘-fno-implicit-inline-templates’ will never emit code for implicit instantiations of inline templates. The default is ‘-fno-implicit-inline-templates’.

-fimplicit-templates (C++ Only)

-fno-implicit-templates (C++ Only)

‘-fimplicit-templates’ instructs the compiler to emit code for non-inline templates which are instantiated implicity. ‘-fno-implicit-templates’ will never emit code for non-inline templates which are instantiated implicitly (i.e. by use); it will only emit code for explicit instantiations.

-finline

-fno-inline

-inline

-INLINE

-noinline

Options ‘-finline’,‘-INLINE’ and ‘-inline’ instruct the compiler to perform inline processing (i.e. expansion of inline functions). If optimizations are not being performed then function inlining is suppressed. ‘-fno-inline’ and ‘-noinline’ disable inlining and don’t pay attention to the inline 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)

‘-finline-functions’ automatically integrates simple functions (i.e. the callees) into the callers. The compiler heuristically decides which functions are simple enough to be worth integrating in this way. If all calls to a given function are integrated, and the function is declared 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)

Instructs the compiler to generate code for functions even if they are fully inlined. In C, emit code for 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

This option group transforms function calls by use of inlining. If inlining directives are inserted in the source code then the ‘-INLINE’ option must be specified in order for those directives to be recognized. Note when specifying the ‘-INLINE’ option the program may not always compile successfully, with the exception of ‘-INLINE:=OFF’ which suppresses the invocation of the lightweight inliner.

-INLINE:all

Instructs the compiler to perform all possible inlining. Note since inlining increases the code size, this option should be specified with some discretion (e.g., use only if program is small).

-INLINE:aggressive=ON|OFF

Instructs the compiler to be very aggressive when performing inlining. The default is ‘-INLINE:aggressive=OFF’.

-INLINE:bias_calls_in_loops=ON|OFF

Instructs the compiler to use a heuristic where functions appearing in loops are more likely to be inlined. The default is ‘-INLINE:bias_calls_in_loops=ON’.

-INLINE:list=ON|OFF

Instructs the compiler to emit a list of inlining transformations as they occur to ‘stderr’. The emitted comments outline which functions are inlined, which functions are not inlined, and why. The default is ‘-INLINE:list=OFF’.

-INLINE:must=name1[,name2,...]

-INLINE:never=name1[,name2,...]

Functions can be tagged for inlining by specifying the function name when using the ‘-INLINE:must’ option or suppressed by using the option ‘-INLINE:never’. Note when using this option in C++, use the C++ mangled name for the function.

-INLINE:none

Disables automatic inlining specified by the interprocedural analysis group option (‘-IPA:’). Note inlining specified by a command-line option or implied by the language are still performed. The default is automatic inlining is turned ON.

-INLINE:preempt=ON|OFF

Inline functions labeled preemptible in the lightweight inliner. Preempt inlining prevents alternate definitions of a function, in another dynamic shared object (DSO), from preempting the definition of the function being inlined. The default is ‘-INLINE:preempt=OFF’.

-ipa

-IPA

-IPA:

Instructs the compiler to invoke interprocedural analysis. These options are identical. The default settings for the ‘-IPA:question=answer’ option group are invoked. Specifying ‘-ipa’ is equivalent to ‘-IPA’ and ‘-IPA:’ with no suboptions.

-IPA:question=answer

The ‘-IPA:’ option group commands the compiler to perform interprocedural analysis and optimization. Interprocedural analysis and optimization can include: inlining, common block array padding, constant propagation, dead function elimination, alias analysis, and others. If the option group defaults are acceptable for compilation then ‘-IPA:’ can be specified without specifying arguments. Note if compiling and linking are performed in separate steps then ‘-IPA:’ must be specified for compilation step and for the link step. An error will occur if ‘-IPA:’ is specified for the compile step and not for the link step.

-IPA:addressing=ON|OFF

Enabling this option invokes the analysis of address operator usage. Setting ‘-IPA:alias=ON’ is a prerequisite for this option. The default is ‘-IPA:addressing=OFF’.

-IPA:aggr_cprop=ON|OFF

The compiler is instructed to perform aggressive interprocedural constant propagation. Interprocedural constant propagation is a process which replaces formal parameters by their corresponding constant values. This process strives to prevent passing constant parameters. The conventional interprocedural constant propagation (‘-IPA:cprop=ON’) is performed by default. The default is ‘-IPA:aggr_cprop=OFF’.

-IPA:alias=ON|OFF

The compiler is instructed to perform ALIAS, 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

The compiler is instructed not to allow inlining of functions with a compiler-evaluated internal code size larger than the limit set by N. The default is ‘-IPA:callee_limit=500’.

-IPA:cgi=ON|OFF

The compiler is instructed to identify constant global variables. The compiler tags all non-scalar global variables which are not modified as constants, and never passes their constant values to all programs. The default is ‘-IPA:cgi=ON’.

-IPA:clone_list=ON|OFF

The compiler is instructed to use the interprocedural analysis function cloner to list all cloning actions performed by the compiler to ‘stderr’. The default is ‘-IPA:clone_list=OFF’.

-IPA:common_pad_size=N

The compiler is instructed to pad common block array dimensions by the value N. By default, the compiler automatically chooses the amount of padding to improve cache behavior for common block array accesses. The default is ‘-IPA:common_pad_size=0’.

-IPA:cprop=ON|OFF

The compiler is instructed to perform interprocedural constant propagation. Interprocedural constant propagation is a process which replaces formal parameters that always have a specific constant values. The default is ‘-IPA:cprop=ON’.

-IPA:ctype=ON|OFF

Instructs the compiler to generate accelerated versions of the <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:depth=N’ is equivalent to ‘-IPA:maxdepth=N’.

-IPA:dfe=ON|OFF

The compiler is instructed to perform “dead function elimination” (dfe). The compiler removes all subprograms/functions which are never called from the program. Note when a function call is replaced by inlining the function everywhere in the program then the original function becomes a “dead function” and is eliminated. The default is ‘-IPA:dfe=ON’.

-IPA:dve=ON|OFF

The compiler is instructed to perform “dead variable elimination” (dve). The compiler removes all variables which are never referenced by the program. The default is ‘-IPA:dve=ON’.

-IPA:echo=ON|OFF

Instructs the compiler to echo the compiler and final link commands which are invoked from IPA to ‘stderr’. ‘-IPA:echo=ON’ can assist in monitoring the progress of a large class program build. The default is ‘-IPA:echo=OFF’.

-IPA:field_reorder=ON|OFF

The compiler is instructed to reorder fields in large structures based on the fields reference patterns in feedback compilation. The field reordering minimizes data cache misses. The default is ‘-IPA:field_reorder=OFF’.

-IPA:forcedepth=N

When attempting to inline functions, the compiler is instructed to limit the depth in the callgraph to N. Note depth 0 refers to functions making no calls, depth 1 are those calling only depth 0 functions, and so on. By default ‘-IPA:forcedepth’ is ignored and the heuristic limits on inlining are in effect.

-IPA:ignore_lang=ON|OFF

When performing inlining, the compiler is instructed to ignore language boundaries (i.e. inlining across the Fortran language to C/C++ language boundary). Note the compiler may not always be cognizant of the proper language semantics and this optimization may have effects at runtime producing unreliable or improper conclusions. The default is ‘-IPA:ignore_lang=OFF’.

-IPA:inline=ON|OFF

The compiler is instructed to perform inter-file subprogram inlining during main interprocedural analysis processing. The default is ‘-IPA:inline=ON’.

-IPA:keeplight=ON|OFF

Specifying the flag ‘-keeplight’ instructs the compiler to save space. The default is ‘-IPA:keeplight=OFF’.

-IPA:linear=ON|OFF

The compiler is instructed to perform linearization of array references. The compiler transforms a multi-dimensional array to a linear array (i.e. single dimensional)which is mapped to the same memory block. The compiler attempts to map formal array parameters to the shape of the actual parameter when inlining Fortran subroutines. This mapping process may not always be successful, therefore when the compiler is unable to map the parameter it linearizes the array reference. Note the compiler will not attempt to inline such callsites due to possible performance problems. The default is ‘-IPA:linear=OFF’.

-IPA:map_limit=N

The interprocedural analysis process uses N as a threshold to trigger invoking ‘-IPA:sp_partition’. When the size of the input files mapped exceeds the limit, N bytes, the compiler enables ‘-IPA:sp_partition’. The default is ‘-IPA:map_limit’ is ignored.

-IPA:maxdepth=N

The compiler is instructed to not attempt to inline functions at a depth in the callgraph which exceeds N. Note depth 0 refers to functions making no calls, depth 1 are those calling only depth 0 functions, and so on. By default ‘-IPA:maxdepth’ is ignored and the heuristic limits on inlining are in effect.

-IPA:max_jobs=N

The compiler is instructed to limit the number of compilation running at once to N. After interprocedural analysis is performed the compiler is invoked with ‘-IPA:max_job’ set to the maximum level of parallelism. N can be set to:

0

The maximum level of parallelism is limited to the greatest number of:

• - CPUs (or processor sockets),
• - processor cores,
• - or hyperthreading units

in the system.

1

Suppress parallelization during compilation.

>=2

Sets the desired level of parallelism

The default is ‘-IPA:max_jobs=1’.

-IPA:min_hotness=N

The compiler is instructed not to inline a function to a call site (i.e. caller) unless the callee is invoked more than N times. The compiler examines the interprocedural feedback to determine if the threshold set by N is surpassed by a call site to a procedure and then proceeds to inline the procedure if the limit is exceeded. The default is ‘-IPA:min_hotness=10’.

-IPA:multi_clone=N

Specifies to the compiler the maximum number of clones of a single procedure the compiler can create. Setting N to a large number promotes more opportunities for interprocedural optimizations. Note significant increase in code size may occur if aggressive procedural cloning is performed. The default is ‘-IPA:multi_clone=0’.

-IPA:node_bloat=N

When the compiler is invoked with option ‘-IPA:multi_clone’, ‘-IPA:node_bloat’ can be specified to gage the code size growth due to procedural cloning. N specifies the maximum percentage of code size growth (i.e. relative to the original code size) due to the total number of procedures cloned. The default is ‘-IPA:node_bloat=100’.

-IPA:plimit=N

The compiler is instructed to halt inlining within a program once the intermediate representation indicates that the code size of the program has surpassed the limit set by N. The default is ‘-IPA:plimit=2500’.

-IPA:pu_reorder=0|1|2

The compiler is instructed to examine compilation feedback for invocation patterns to determine the process of reordering the layout of program procedures in order to minimize instruction cache misses. Possible settings are:

0

Suppress reordering of program procedures.

1

Use the frequent occurrence of procedure invocation to determine reordering.

2

Use the relationship between caller and callee to determine reordering.

The default is ‘-IPA:pu_reorder=1’ for C++ programs and ‘-IPA:pu_reorder=0’ for non-C++ programs.

-IPA:relopt=ON|OFF

The compiler is instructed to build objects under the presumption that the compiled objects will be linked into a call-shared executable. The default is ‘-IPA:relopt=OFF’. When invoked as ‘-IPA:relopt=ON’, optimizations based on position-dependent code (non-PIC) will be performed on the compiled objects. Note ‘-IPA:relopt’ is similar to invoking the compiler using ‘-O’ and ‘-c’.

-IPA:small_pu=N

The compiler is instructed not to restrict a procedure from inlining with a code size smaller than N when invoking the ‘-IPA:plimit’ flag. The default is ‘-IPA:small_pu=30’.

-IPA:sp_partition=ON|OFF

The compiler is instructed to use partitioning when building huge programs. Note partitioning is normally performed internal to the IPA. This option is invoked to conserve disk and memory space. The default is ‘-IPA:sp_partition=OFF’

-IPA:space=N

The compiler is instructed to perform inlining until the program code size expands by percentage specified by N. Therefore, to limit program code size growth to ~20%, due to inlining, specify ‘-IPA:space=20’. The default is ‘-IPA:space=’infinity.

-IPA:specfile=filename

When invoking the compiler with option ‘IPA:specfile’, the user indicates that a file, filename, containing additional options exist. The specified file must contain zero or more lines with the additional options in the proper command line syntax. Note the nesting of ‘-IPA:specfile’ is not permitted.

-IPA:use_intrinsic=ON|OFF

The compiler is instructed to load the intrinsic version of standard library functions. Note ‘-IPA:use_intrinsic’ may promote the inlining of the malloc library function. This option improves small object allocations. The default is ‘-IPA:use_intrinsic=OFF’.

3.9.5 Options that Control Loop Nest Optimizations

-LNO:question=answer

This option group commands the compiler loop nest optimizer to perform nested loop analysis and transformations. Note an optimization level of ‘-O3’ or higher must be specified in order to enable the ‘-LNO:’options.

To verify the LNO options that were invoked during compilation use the option ‘-LIST:all_options=ON’.

-LNO:apo_use_feedback=ON|OFF

Instructs the auto-parallelizer to use the feedback data of the loops in deciding if each loop should be parallelized. This option will only be invoked if ‘-apo’ under feedback-directed compilation has been enabled. The compiler creates a serial and parallel version of a parallelized loop and if the loop trip count is small the serial version is used during execution. When ‘-LNO:apo_use_feedback=ON’ and the feedback data validates that the loop trip count is small the auto-parallelizer will not create the parallel version (i.e. optimizing the runtime by eliminating the conditional code required to determine the use of the serial or parallel version). The default is ‘-LNO:apo_use_feedback=OFF’.

-LNO:build_scalar_reductions=ON|OFF

The compiler is instructed to build scalar reductions before performing any loop transformation analysis and implementing any loop reduction transformations. Note when ‘-OPT:roundoff=2’ or greater is specified then this flag is repetitious. The default is ‘-LNO:build_scalar_reductions=OFF’.

-LNO:blocking=ON|OFF

Instructs the compiler to perform cache blocking transformation. The default is ‘-LNO:blocking=ON’

-LNO:blocking_size=N

Instructs the compiler to use the specified block size, N, when performing all blocking. Note N represents the number of iterations and must be a positive integer.

-LNO:fission=0|1|2

Instructs the compiler to perform loop fission. This option can be set to:

0

Suppress loop fission.

1

The compiler performs normal loop fission as necessary.

2

The compiler performs loop fission prior to loop fusion.

Note 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

The compiler is instructed to fully unroll loops after examining the loop, within the loop nest optimizer, to determine if the loop can be fully unrolled in N or less iterations. Argument ‘fu=N’ specifies the maximum number of unrolls that can be performed to fully unroll the loop. Note setting N=0 suppresses full unrolling of loops inside the loop nest optimizer. ‘-LNO:fu’ is the abbreviated form for ‘-LNO:full_unroll’. The default is ‘-LNO:full_unroll=5’

-LNO:full_unroll_size=N

The compiler is instructed to fully unroll loops after examining the loop, within the loop nest optimizer, to determine if the unrolled loop size is less than or equal to N. Specify N as an integer between 0 and 10000. Note limits set by ‘-LNO:full_unroll=N’ and ‘-LNO:full_unroll_size=N’ must be satisfied before the loop is fully unrolled. The default is ‘-LNO:full_unroll_size=2000’

-LNO:full_unroll_outer=ON|OFF

The compiler is instructed to “fully” unroll loops that do not include inner loops or is included by an outer loop. Note limits set by both ‘-LNO:full_unroll=N’ and ‘-LNO:full_unroll_size=N’ must be satisfied before the loop is fully unrolled. The default is ‘-LNO:full_unroll_outer=OFF’

-LNO:fusion=0|1|2

The compiler is instructed to perform loop fusion. The flag can be set to:

0

Suppress loop fusion.

1

The compiler performs traditional loop fusion

2

The compiler performs aggressive loop fusion

The default is ‘-LNO:fusion=1’.

-LNO:fusion_peeling_limit=N

The compiler is instructed to implement loop peeling during loop fusion. N sets the limit on the number of loop peeling iterations. Note N must be greater than or equal to zero. The default is ‘-LNO:fusion_peeling_limit=5’.

-LNO:gather_scatter=0|1|2

Instructs the compiler to perform gather-scatter optimizations. The flag can be set to:

0

Suppress gather-scatter optimizations.

1

The compiler performs gather-scatter optimizations to non-nested IF statements.

2

The compiler performs multi-level gather-scatter optimizations.

The default is ‘-LNO:gather_scatter=1’.

-LNO:hoistif=ON|OFF

The compiler is instructed to hoist IF statements which reside inside inner loops. This optimization will eliminate redundant loops. The default is ‘-LNO:hoistif=ON’.

-LNO:ignore_feedback=ON|OFF

The compiler is instructed to ignore feedback information generated by loop annotations during loop nest optimizations. The default is ‘-LNO:ignore_feedback=OFF’.

-LNO:ignore_pragmas=ON|OFF

Instructs the compiler to use command-line options instead of the corresponding directives in the source code. The default is ‘-LNO:ignore_pragmas=OFF’.

-LNO:local_pad_size=N

The compiler is instructed to pad local array dimensions by the amount specified in N. The default is to instruct the compiler to choose the padding required to optimize cache behavior for local array access.

-LNO:minvariant=ON|OFF

-LNO:minvar=ON|OFF

The compiler is instructed to move loop-invariant expressions outside of loops. ‘-LNO:minvar’ is the abbreviated form for ‘-LNO:minvariant’. The default is ‘-LNO:minvariant=ON’

-LNO:non_blocking_loads=ON|OFF (C/C++ Only)

Instructs the compiler that the target processor blocks on loads. The default is specified by the host processor in use.

-LNO:oinvar=ON|OFF

The compiler is instructed to perform outer loop invariant hoisting. The default is ‘-LNO:oinvar=ON’

-LNO:opt=0|1

Instructs the compiler at which level to perform loop nest optimizations. The flag can be set to:

0

The compiler is restricted by suppress nearly all loop nest optimizations.

1

The compiler performs full loop nest optimizations.

The default is ‘-LNO:opt=1’

-LNO:ou_prod_max=N

The compiler is instructed to unroll several outer loops of a given loop nest. The product is limited to N outer loops. Note specify N as a positive number. The default is ‘-LNO:ou_prod_max=16’.

-LNO:outer=ON|OFF

The compiler is instructed to perform outer loop fusion. The default is ‘-LNO:outer=ON’.

-LNO:outer_unroll_max=N

-LNO:ou_max=N

The compiler is instructed to perform the unrolling of outer loops of a loop nest. The unrolling of the outer loop is limited to N unrolls per outer loop. ‘-LNO:ou_max’ is the abbreviated form for ‘-LNO:outer_unroll_max’. The default is ‘-LNO:outer_unroll_max=5’.

-LNO:parallel_overhead=N

Specifying the auto-parallelizing option, ‘-apo’, instructs the compiler to generate a serial and parallel instance of a loop. Specifying ‘-LNO:parallel_overhead’ in conjunction with ‘-apo’ instructs the compiler to estimate the overhead involved when invoking the parallel instance of the loop taking into account the number of processors and loop iterations. The loop nest optimizer then uses N to determine if the overhead exceeds the performance benefit during execution time. Note using this flag with auto-parallelizer can be used to tune parallel performance across various platforms and programs. The default is ‘-LNO:parallel_overhead=4096’.

-LNO:prefetch=0|1|2|3

Instructs the compiler to perform prefetching optimizations at a specified level. The flag can be set to:

0

Instructs the compiler to suppress prefetching.

1

The compiler is instructed to allow prefetching only for arrays that are always referenced in every loop iteration.

2

The compiler is instructed to implement prefetching disregarding the restrictions in the above setting.

3

The compiler is instructed to implement aggressive prefetching.

The default is ‘-LNO:prefetch=2’.

-LNO:prefetch_ahead=N

The compiler is instructed to prefetch ahead N cache line(s). The default is ‘-LNO:prefetch_ahead=2’.

-LNO:prefetch_verbose=ON|OFF

Instructs the compiler to print verbose prefetch information to ‘stdout’. The default is ‘-LNO:prefetch_verbose=OFF’.

-LNO:processors=N

‘-LNO:processors’ is used in conjunction with ‘-apo’ and instructs the compiler to assume that the generated code will be executed on a given number of processors installed on the target system. Specifying this flag assists in decreasing the computation time during execution when determining which loop instance to execute (i.e. serial or parallel). See ‘-LNO:parallel_overhead flag’. Setting N=0 indicates the code should be compiled for a unknown number of processors and should be used when compiling programs that will be executed on platforms with different number of processors. Note the parallelized code will not perform optimally if N is set to a number that is different from the number of processors available in the target system. The default is ‘-LNO:processors=0’.

-LNO:sclrze=ON|OFF

The compiler is instructed to substitute a scalar variable for an array. The default is ‘-LNO:sclrze=ON’.

-LNO:simd=0|1|2

The compiler is instructed to use single instruction multiple data (SIMD) instructions, supported by the target processor, when vectorizing the inner loop. The flag can be set to:

0

The compiler is instructed to suppress vectorization.

1

The compiler is instructed to vectorize only if there is no performance degradation due to sub-optimal alignment and does not induce floating-point operation inaccuracies.

2

Instructs the compiler to aggressively vectorize with no constraints in place.

The default is ‘LNO:simd=1’.

-LNO:simd_reduction=ON|OFF

The compiler is instructed to vectorize reduction loops. The default is ‘-LNO:simd_reduction=ON’.

-LNO:simd_verbose=ON|OFF

Instructs the compiler to print verbose vectorizer information to ‘stdout’. The default is ‘-LNO:simd_verbose=OFF’.

-LNO:svr_phase1=ON|OFF

Instructs the compiler to implement the scalar variable naming phase prior to the first phase of the loop nest optimizer. The default is ‘-LNO:svr_phase1=ON’.

-LNO:trip_count_assumed_when_unknown=N

-LNO:trip_count=N

The compiler is instructed to use the value N as a presumed loop trip-count if at compile time a loop trip-count is not known. The loop trip-count, N, is used for loop transformations and prefetch optimizations and must be a positive integer. Note ‘-LNO:trip_count’ is the abbreviated form. The default is ‘-LNO:trip_count=1000’.

-LNO:vintr=0|1|2

The compiler is instructed to use vector intrinsic functions when vectorizing loops. Where a vector function is called once to compute a math intrinsic for the entire vector. The flag can be set to:

0

Instructs the compiler to suppress vector intrinsic function optimizations.

1

The compiler is instructed to perform normal vector intrinsic function optimizations.

2

The compiler is instructed to aggressively implement all vector intrinsic function optimizations. Note specifying this option could cause some of the vector intrinsic functions to produce floating-point accuracy errors.

The default is ‘-LNO:vintr=1’.

-LNO:vintr_verbose=ON|OFF

Instructs the compiler to print verbose vector intrinsic optimization status to ‘stdout’. The status report will list loops that are vectorized using vector intrinsic functions. The default is ‘-LNO:vintr_verbose=OFF’.

The following Loop Transformation Suboptions allow the user to control cache blocking, loop unrolling, and loop interchange.

-LNO:interchange=ON|OFF

The compiler is instructed to perform loop interchange optimizations. The default is ‘-LNO:interchange=ON’.

-LNO:unswitch=ON|OFF

The compiler is instructed to perform simple loop unswitching transformations. The default is ‘-LNO:unswitch=ON’.

-LNO:unswitch_verbose=ON|OFF

Instructs the compiler to print verbose loop unswitching report to ‘stdout’. The default is ‘-LNO:unswitch_verbose=OFF’.

-LNO:outer_unroll=N

-LNO:ou=N

The compiler is instructed to unroll all outer loops by N iterations, i.e. when valid. The loop unrolling process is performed for N iterations or is not performed at all. ‘-LNO:ou’ is the abbreviated form for ‘-LNO:outer_unroll’. N must be a positive integer.

-LNO:outer_unroll_deep=ON|OFF

-LNO:ou_deep=ON|OFF

The compiler is instructed to unroll the outer wind down loops which is a result of unrolling outer loops further-out. This transformation is valid for loops nested three or more deep. Note this optimization generates faster runtime code, but increase code size. Option ‘-LNO:ou_deep’ is the abbreviated form. The default is ‘-LNO:outer_unroll_deep=ON’.

-LNO:outer_unroll_further=N

-LNO:ou_further=N

The compiler is instructed to perform outer loop unrolling on wind down loops. The value N sets a limit on the number of iterations for unrolling wind down loops. Set N to a positive integer. Note: Specifying ‘-LNO:outer_unroll_further=999999’ suppress unrolling. Specifying ‘-LNO:outer_unroll_further=3’ sets a rational limit to unrolling.

Option ‘-LNO:ou_further’ is the abbreviated form. The default is ‘ou_further=6’.

-LNO:outer_unroll_max=N

-LNO:ou_max=N

The compiler is instructed to unroll a limit of N copies-per-loop. Option ‘-LNO:ou_max’ is the abbreviated form.

-LNO:pwr2=ON|OFF (C/C++ Only)

When ‘-LNO:pwr2=OFF’ the compiler is instructed to disregard the leading dimension. The default is ‘-LNO:pwr2=ON’.

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

Instructs the compiler to set cache associativity. Setting N to a large number, e.g. 128, specifies a fully associative cache (e.g., main memory). Note specify N as a positive integer. Setting N=0 specifies that no cache exist at that level.

-LNO:cmpl=N, cmp2=N, cmp3=N, cmp4=N, dmp1=N, dmp2=N, dmp3=N, dmp4=N

The compiler is instructed to set the time to process a clean miss (e.g. cmpx=N) or a dirty miss (e.g. dmpx=N) to the next level of the memory hierarchy. The value in N is representative of processor cycles and is approximate due to its dependency on a clean or dirty line, read or write miss, etc. Note specify N as a positive integer. Setting N=0 specifies that no cache exist at that level.

-LNO:cs1=N. cs2=N, cs3=N, cs4=N

The compiler is instructed to set the cache sizes. The value in N must include a suffix letter of k or K to indicate Kbytes or m or M to indicate Mbytes. Note specify N as a positive integer. Setting N=0 specifies that no cache exist at that level.

Note:

• - primary cache is represented by cs1
• - secondary cache is represented by cs2
• - memory is represented by cs3
• - disk is represented by cs4

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|OFF

The compiler is instructed to setup the memory model hierarchy as cache or memory.

An 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=N

The compiler is instructed to set the cache line sizes. The value in N is the number of bytes in a cache line. The size of the cache line dictates the number of bytes moved from one memory hierarchy on a miss at this level to another memory hierarchy level. Note specify N as a positive integer. Setting N=0 specifies that no cache exist at that level.

The following LNO Translation Lookaside Buffer Suboptions allows the user to specify the translation lookaside buffer (TLB) characteristics. 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

The compiler is instructed to set the page table size. The value in N is the number of bytes in the page. Note specify N as a positive integer. The default for N is dependent on the target system hardware.

-LNO:tlb1=N, tlb2=N, tlb3=N, tlb4=N

The compiler is instructed to set the number of entries, N, in the TLB for a selected memory hierarchy level. Note specify N as a positive integer. The default for N is dependent on the target system hardware.

-LNO:tlbcmp1=N, tlbcmp2=N, tlbcmp3=N, tlbcmp4=N, tlbdmp1=N, tlbdmp2=N, tlbdmp3=N, tlbdmp4=N

The compiler is instructed to set the time to service a clean TLB miss (e.g. tlbcmpx=N) or a dirty TLB miss (e.g. dmpx=N) to the next level of the memory hierarchy. The value in N is representative of processor cycles and is approximate. Note specify N as a positive integer. The default for N is dependent on the target system hardware.

The following LNO Prefetch Suboptions allows the user to specify prefetch operations.

-LNO:pf1=ON|OFF, pf2=ON|OFF, pf3=ON|OFF, pf4=ON|OFF

The compiler is instructed to turn ON/OFF prefetching for specified cache levels.

-LNO:prefetch=0|1|2|3

The compiler is instructed to set the prefetching level. The flag can be set to:

0

Instructs the compiler to suppress prefetching.

1

Instructs the compiler to set prefetching only for arrays that are referenced in every loop iteration.

2

Instructs the compiler to turn prefetching ON disregarding the above restriction.

3

Instructs the compiler to perform aggressive prefetching.

The default is ‘-LNO:prefetch=2’

-LNO:prefetch_ahead=N

The compiler is instructed to prefetch a set number, N, of cache lines ahead of the reference. Note specify N as a positive number. The default is ‘-LNO:prefetch_ahead=2’.

-LNO:prefetch_manual=ON|OFF

The compiler is instructed to allow directives specifying manual prefetches. If ‘-LNO:prefetch_manual=OFF’ the directives are ignored. The default is ‘-LNO:prefetch_manual=ON’.

3.10 Options Controlling the Preprocessor

These 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

Make an assertion with the predicate predicate and answer answer. Option ‘-A -predicate=answer’ cancels an assertion with the predicate predicate and answer answer.

-C (C Only)

Do not discard comments after preprocessing. All comments are passed through to the output file, except for comments in processed directives, which are deleted along with the directive.

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 ‘#’.

-cpp

Instructs the compiler to pass all input source code through the GCC preprocessor (i.e. the C preprocessor, cpp) before compiling, regardless of the ‘filename’ suffix.

Note 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

The compiler is instructed to generate and write a specified list to the standard output file. Note CHAR is a sequence of one or more of the following characters, and must not be preceded by a space. Other characters are interpreted by the compiler proper, or reserved for future versions of Open64, and so are silently ignored. If you specify characters whose behavior conflicts, the result is undefined.

-dD

Generate a list of non-predefined macro directives.

-dI

Output #include directives in addition to preprocessor results.

-dM

Generate a list of directives for all macros.

-dN

Generate a list of all macro names defined.

-Dname

Predefine name as a macro, with definition 1. 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,...]

The contents of definition are tokenized and processed as if they appeared during translation phase three in a ‘#define’ directive. In particular, the definition will be truncated by embedded newline characters. The preprocessor assigns values to the constants preempting values assigned within the source files. When the option contains an “=” sign the value on the right must be an integer and the name on the left must be declared as an integer constant in the source files.

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'’.

-fe

Instruct the compiler to halt after the prepreocessor is run (i.e. the compiler front-end).

-fpreprocessed (C/C++ Only)

-fno-preprocessed (C/C++ Only)

Instructs the compiler that the input source file has been preprocessed. ‘-fno-preprocessed’ specifies that the input source file has not been preprocessed.

-ftpp (Fortran Only)

Fortran source files are processed by the Fortran source preprocessor before compiling.

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

-M

Instead of outputting the result of preprocessing, output a rule suitable for make describing the dependencies of the main source file. The preprocessor outputs one make rule containing the object file name for that source file, a colon, and the names of all the included files, including those coming from ‘-include’ or ‘-imacros’ command line options.

Unless 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)

The preprocessor performs macro expansion throughout each Fortran source file. When option is not specified macro expansion is limited to preprocessor # directives only.

-MD

‘-MD’ is equivalent to ‘-M -MF file’, except that ‘-E’ is not implied. The driver determines file based on whether an ‘-o’ option is given. If it is, the driver uses its argument but with a suffix of ‘.d’, otherwise it takes the basename of the input file and applies a ‘.d’ suffix.

If ‘-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)

Use filename as the target for makefile dependencies. Used in conjunction with the option ‘-MDupdate’.

-MDupdate filename (Fortran Only)

Updates makefile dependencies in filename.

-MF filename

When used with ‘-M’ or ‘-MM’, specifies a filename to write the dependencies to. If no ‘-MF’ switch is given the preprocessor sends the rules to the same place it would have sent preprocessed output.

When used with the driver options ‘-MD’ or ‘-MMD’, ‘-MF’ overrides the default dependency output file.

-MG

In conjunction with an option such as ‘-M’ or ‘-MM’ requesting dependency generation, ‘-MG’ assumes missing header files are generated files and adds them to the dependency list without raising an error. The dependency filename is taken directly from the #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.

-MM

Like ‘-M’ but do not mention header files that are found in system header directories, nor header files that are included, directly or indirectly, from such a header.

This 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

Like ‘-MD’ except mention only user header files, not system header files.

-MP

This option instructs CPP to add a phony target for each dependency other than the main file, causing each to depend on nothing. These dummy rules work around errors make gives if you remove header files without updating the ‘Makefile’ to match.

This is typical output:

test.o: test.c test.h test.h:

-MQ target (C/C++ Only)

Same as ‘-MT’, but it quotes any characters which are special to Make. ‘-MQ '$(objpfx)foo.o'’ gives

$$(objpfx)foo.o: foo.c

The default target is automatically quoted, as if it were given with ‘-MQ’.

-MT target (C/C++ Only)

Change the target of the rule emitted by dependency generation. By default CPP takes the name of the main input file, including any path, deletes any file suffix such as ‘.c’, and appends the platform’s usual object suffix. The result is the target.

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)

Do not run the source preprocessor (cpp) on all input source files. See ‘-cpp’, ‘-E’, and ‘ftpp’ for more information on controlling preprocessing.

-no-gcc (Fortran Only)

Disables predefined preprocessor macros, e.g. __GNUC__

-P

Inhibit generation of linemarkers in the output from the preprocessor. This might be useful when running the preprocessor on something that is not C code, and will be sent to a program which might be confused by the linemarkers. Used with option ‘-E’, See option ‘-E’ in Option Controlling the Kind of Output section.

-Uname

Cancel any previous definition of name, either built in or provided with a ‘-D’ option.

-Wp,option,...

You can use ‘-Wp,option’ to bypass the compiler driver and pass option directly through to the preprocessor. If option contains commas, it is split into multiple options at the commas. However, many options are modified, translated or interpreted by the compiler driver before being passed to the preprocessor, and ‘-Wp’ forcibly bypasses this phase. The preprocessor’s direct interface is undocumented and subject to change, so whenever possible you should avoid using ‘-Wp’ and let the driver handle the options instead.

3.11 Passing Options to the Assembler

You can pass options to the assembler.

-fno-asm (C/C++ Only)

Do not recognize 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,...

Pass option as an option to the assembler. If option contains commas, it is split into multiple options at the commas.

3.12 Options Controlling the Linker and Libraries

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.

object-file-name

A file name that does not end in a special recognized suffix is considered to name an object file or library. (Object files are distinguished from libraries by the linker according to the file contents.) If linking is done, these object files are used as input to the linker.

-ar

Instructs the compiler to create an archive file instead of a shared object or executable file. To specify an archive file name use ‘-o filename’. Before creating the archive file, template entities needed by the archived objects are instantiated. When openCC invokes the compiler with ‘-ar’ specified, it implicitly passes options ‘-c’ and ‘-r’ to the compiler. In addition the filename of the archive and object files being created are passed. Option ‘-WR,option-list’is used to pass required options that can be used concurrently with the ‘-c’ option.

Note 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

If any of these options is used, then the linker is not run, and object file names should not be used as arguments. See Overall Options.

-ffast-stdlib

-fno-fast-stdlib

Instructs the compiler to generate code that links against special versions of some standard library routines (e.g., fast versions of the standard library routines). Specifying ‘-fno-fast-stdlib’ instructs the compiler not to generate code that links against fast versions of standard library routines. Linking code with ‘-fno-fast-stdlib’ that has not been compiled using this flag may emit linker errors. Note specifying ‘-ffsat-stdlib’ implies ‘-OPT:fast_stdlib=ON’. The default is ‘-ffast-stdlib’.

-H

Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the ‘#include’ stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ‘...x’ and a valid one with ‘...!’ .

-l library

Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)

It 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

Do not use the standard system startup files when linking. The standard system libraries are used normally, unless ‘-nostdlib’ or ‘-nodefaultlibs’ is used.

-nodefaultlibs

Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. The standard startup files are used normally, unless ‘-nostartfiles’ is used. The compiler may generate calls to memcmp, 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

Instructs the compiler to skip the standard directory (i.e. ‘/usr/include/’) when searching for #include files and files named in the INCLUDE statements.

-nostdinc++ (C++ Only)

Do not search for header files in the standard directories specific to C++, but do still search the other standard directories. (This option is used when building the C++ library.)

-nostdlib

Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker. The compiler may generate calls to memcmp, 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

Instructs the compiler to open filename to retrieve the list of files to be linked.

-shared

Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (‘-fpic’, ‘-fPIC’, or model suboptions) when you specify this option.(1)

Note care should be taken mixing ‘-shared’ with ‘-IPA’ options. Interprocedural analysis assumes the compiler sees the entire program to perform optimizations. Incorrect programs can be produced when only part of a program is placed in a shared library.

-shared-libgcc

-static-libgcc

On systems that provide ‘libgcc’ as a shared library, these options force the use of either the shared or static version respectively. If no shared version of ‘libgcc’ was built when the compiler was configured, these options have no effect.

There 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

On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. ‘--static’ is equivalent to ‘-static’, except ‘--static’ does not incite the compiler to emit warnings regarding possible confusion with ‘-static-data’.

-static-data (Fortran Only)

Instructs the compiler to statically allocate all local variables which are initially set to zero and will exist for the life of the program. Global data is allocated as part of the compiled object file. The total size of any object file is limited to 2 GB. The total size of a program loaded using multiple object files are allowed to exceed the 2 GB limit. Multiple common blocks each within the 2 GB size limit can be declared.

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

Instructs the compiler to use a predefined include search path list.

-symbolic

Bind references to global symbols when building a shared object. Warn about any unresolved references (unless overridden by the link editor option ‘-Xlinker -z -Xlinker defs’). Only a few systems support this option.

-Xlinker option

Pass option as an option to the linker. You can use this to supply system-specific linker options which the compiler does not know how to recognize.

If 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,...

Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas.

3.13 Options for Code Generation Conventions

These machine-independent options control the interface conventions used in code generation.

-CG:question=answer

This group of code generation option controls the optimizations and transformations of the instruction level code generator.

-CG:cflow=ON|OFF

‘-CG:cflow=OFF’ disables control flow optimization in the code generation. The default is ‘-CG:cflow=ON’.

-CG:cmp_peep=ON|OFF

Instructs the compiler to perform aggressive load execution peeps on compare operations. The default is ‘CG:cmp_peep=OFF’.

-CG:compute_to=on|off

Instructs the compiler to allow local code motion to take advantage of pipeline optimizations. For example: specify in conjunction with option ‘-march=barcelona’, i.e.when targeting versions of the Quad-Core AMD® Opteron^T^M and greater. The default is ‘CG:compute_to=OFF’

-CG:cse_regs=N

When performing common subexpression elimination, instructs the compiler code generator that there are N extra integer registers available (i.e. in excess of the number provided by the CPU). N can be positive, negative, or zero. The default is positive infinity. See ‘-CG:sse_cse_regs=N’.

-CG:divrem_opt=ON|OFF

Invokes a local optimization where integer expressions of a % b when b is a power of two and b is greater than 0, are replaced with if (a > 0) a & (b-1) else (a % b). The default is ‘-CG:divrem_opt=OFF’.

-CG:gcm=ON|OFF

‘-CG:gcm=OFF’ instructs the compiler to disable the instruction level global code motion optimization phase. The default is ‘-CG:gcm=ON’.

-CG:inflate_reg_request=N

Instructs the the local register allocator to increase its register request by N percent for innermost loops. The default is ‘-CG:inflate_reg_request=0’.

-CG:load_exe=N

The parameter N must be a non-negative integer which specifies the threshold for the compiler to consider folding a memory load operation directly into its subsequent use in an arithmetic instruction (thereby eliminating the memory load operation). If N=0 this folding optimization is not performed (in other words, the optimization is turned off). If the number of times the result of the memory load is used exceeds the value of N, then the folding optimization is not performed. For example, if N=1 this optimization is performed only when the result of the memory load has only one use. The default value of N varies with target processor and source language.

-CG:local_sched_alg=0|1|2

This option selects the basic block instruction scheduling algorithm.

• - To perform backward scheduling (i.e. where instructions are scheduled from the bottom to the top of the basic block) select 0.
• - To perform forward scheduling select 1.
• - To schedule the instruction twice (i.e. once in the forward direction and once in the backward direction) and take the optimal of the two schedules.

The default value for this option is determined by the x86 Open64 compiler during compilation.

-CG:locs_best=ON|OFF

When enabled the local instruction scheduler is run several times using different heuristics. The optimal schedule generated is selected. Note this option supersedes options which control local instruction scheduling, e.g. ‘-CG:local_sched_alg’ and ‘-CG:locs_shallow_depth’. The default is ‘-CG:locs_best=OFF’.

-CG:locs_reduce_prefetch=ON|OFF

Setting to ON instructs the compiler to delete prefetch instructions that cannot be scheduled into unused processor cycles. Note this occurs only for backward instruction scheduling. The default is ‘-CG:locs_reduce_prefetch=OFF’.

-CG:locs_shallow_depth=ON|OFF

ON instructs the compiler to give priority to instructions that have shallow depths in the dependence graph when performing local instruction scheduling to reduce register usage. The default is ‘-CG:locs_shallow_depth=OFF’.

-CG:movnti=N

When writing memory blocks of size larger than N KB ordinary stores will be transformed to non-temporal stores. The default is N=1000.

-CG:p2align=ON|OFF

When ON instructs the compiler to align loop heads to 64-byte boundaries. The default is ‘-CG:p2align=OFF’.

-CG:p2align_freq=N

Values for N specify the execution frequency threshold. The compiler will perform branch target alignments when the execution frequency is equal to or greater than the specified threshold, N. Note this option is only valid when using feedback-direct compilation. The default is N=1000.

-CG:post_local_sched=ON|OFF

When ON, enables the local scheduler phase after register allocation. The default is ‘-CG:post_local_sched=ON’.

-CG:pre_local_sched=ON|OFF

When ON, enables the local scheduler phase before register allocation. The default is ‘-CG:pre_local_sched=ON’.

-CG:prefer_legacy_regs=ON|OFF

When enabled the compiler register allocator is instructed to use the first 8 integer and SSE registers when possible. Starting with the last assigned register and work upward in most recently assigned fashion where available. Note instructions which use these registers have smaller instruction sizes. For example, the lower 8 registers on x86-64 do not use the rex byte. The default is ‘-CG:prefer_legacy_regs=OFF’.

-CG:prefetch=ON|OFF

When ‘-CG:prefetch=ON’ prefetch instructions are generated in the code generator. Note both ‘-CG:prefetch=OFF’ and ‘-LNO:prefetch=0’ disable the generation of prefetch instructions. Only ‘-LNO:prefetch=0’ affects loop-nesting optimizations that rely on prefetch. The default is ‘-CG:prefetch=OFF’.

-CG:ptr_load_use=N

The code generator increases the latency between an instruction that loads a pointer and an instruction that uses the pointer by N cycles. Ordinarily, it is advantageous to load pointers as fast as possible so the dependent memory instructions can begin execution. However, the additional latency will force the instruction scheduler to schedule the load pointer earlier. Note the load pointer instructions include load-execute instructions which compute pointer results. The default is ‘-CG:ptr_load_use=4’.

-CG:push_pop_int_saved_regs=ON|OFF

When ON, the compiler generates push and pop instructions to save integer callee-saved registers at function prologues and epilogues. The push and pop instructions replace mov instructions to and from memory locations based off the stack pointer. The default is ‘-CG:push_pop_int_saved_regs=OFF’. When the specified target is the Quad-Core AMD Opteron^T^M processor the default is ‘-CG:push_pop_int_saved_regs=ON’.

-CG:sse_cse_regs=N

When performing common subexpression elimination, instructs the compiler code generator that there are N extra SSE registers available (i.e. in excess of the number provided by the CPU). N can be positive, negative, or zero. The default is positive infinity. See ‘-CG:cse_regs=N’.

-CG:strcmp_expand=ON|OFF

The compiler is instructed to try to replace calls to strcmp() with an inline sequence of instructions. The default is ‘-CG:strcmp_expand=ON’.

-CG:unroll_fb_req=ON|OFF

The compiler is instructed to override cold code motion to keep the code generator from adding control flow in unrolled loops. The default is ‘-CG:unroll_fb_req=OFF’.

-CG:use_prefetchnta=ON|OFF

When enabled prefetching is performed on non-temporal data at all levels of the cache hierarchy. Note for data streaming situations when the data will not need to be reused soon. The default is ‘-CG:use_prefetchnta=OFF’.

-CG:use_test=ON|OFF

When enabled the code generator is forced to use TEST instruction instead of the CMP instruction. The default is ‘-CG:use_test=OFF’.

-GRA:question=answer

Global register allocation (GRA) is the process of multiplexing a large number of target program variables onto a small number of CPU registers. The code generator implements global register allocation when certain optimization levels are specified.

-GRA:home=ON|OFF

Instructs the compiler to perform a rematerialization optimization for non-local user variables in the register allocator. The default is ‘-GRA:home=ON’.

-GRA:optimize_boundary=ON|OFF

Instructs the compiler to permit the register allocator to assign the same register to different variables in the same basic-block. The default is ‘-GRA:optimize_boundary=OFF’.

-GRA:prioritize_by_density=ON|OFF

Instructs the compiler’s GRA to prioritize register assignments to variables based on the variable’s reference count density (number of times the variables are referenced in a local region of interest) and not on their global reference count. The default is ‘-GRA:prioritize_by_density=OFF’.

-GRA:unspill=ON|OFF

The compiler is instructed to mitigate existing and suboptimal boundary conditions between global register allocation and local register allocation by unspilling register candidates which were really available at those boundary conditions. The default is ‘-GRA:unspill=OFF’.