Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products
and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. UNIX is a registered
trademark of The Open Group.
Intel® and Itanium® are trademarks of Intel Corporation in the U.S. and other countries.
Contents
HP secure development lifecycle....................................................................17
About This Document ..................................................................................18
Starting with HP-UX 11i v3 March 2013 update release, HP secure development lifecycle provides
the ability to authenticate HP-UX software. Software delivered through this release has been digitally
signed using HP's private key. You can now verify the authenticity of the software before installing
the products, delivered through this release.
To verify the software signatures in signed depot, the following products must be installed on your
system:
•B.11.31.1303 or later version of SD (Software Distributor)
•A.01.01.07 or later version of HP-UX Whitelisting (WhiteListInf)
To verify the signatures, run: /usr/sbin/swsign -v –s <depot_path>. For more information,
see Software Distributor documentation at http://www.hp.com/go/sd-docs.
NOTE:Ignite-UX software delivered with HP-UX 11i v3 March 2014 release or later supports
verification of the software signatures in signed depot or media, during cold installation.
For more information, see Ignite-UX documentation at http://www.hp.com/go/ignite-ux-docs.
About This Document
This manual presents programming information on the C++ programming language, as implemented
on Itanium®- based systems.
The document printing date and part number indicate the document’s current edition. The printing
date will change when a new edition is printed. Minor changes may be made at reprint without
changing the printing date. The document part number will change when extensive changes are
made.
Document updates may be issued between editions to correct errors or document product changes.
To ensure that you receive the updated or new editions, you should subscribe to the appropriate
product support service. Contact your HP sales representative for details.
The latest version of this document is available on the web at http://www.hp.com/go/
hpux-C-Integrity-docs.
Intended Audience
This manual is intended for experienced C and C++ programmers who are familiar with HP systems.
What’s in This Document
HP aC++/HP C Programmer’s Guide is divided into the following chapters:
Chapter 1Getting Started
Gives you an introduction to the HP aC++ product and its components. It also
discusses the compiler command syntax and environment variables.
Chapter 2Command Line Options
Discusses command line options. Command line options are categorized into
different sections based on how you can use them. This chapter also covers
diagnostic messages and pragma directives.
Chapter 3Pragma Directives
Discusses pragmas supported in HP aC++. A pragma directive is an instruction
to the compiler. Use a #pragma directive to control the actions of the compiler
in a particular portion of a translation unit without affecting the translation unit
as a whole.
Chapter 4Preprocessing Directives
Gives you an overview, the syntax, and usage guidelines of preprocessing
directives. This chapter also includes a section on using HP aC++ templates.
Chapter 5Using HP aC++ Templates
Gives you an overview of template processing and describes the instantiation
coding methods available in HP aC++.
Chapter 6Standardizing Your Code
Discusses HP aC++ keywords, Standard Exception Classes, and exceptions
thrown by the Standard C++ library, and lists unsupported functionality.
Chapter 7Optimizing HP aC++ Programs
Gives you information about optimizing your programs.
18
Chapter 8Exception Handling
Discusses exception handling, and information on using threads and parallel
programming.
Chapter 9Tools and Libraries
Discusses the tools and libraries bundled with HP aC++.
Chapter 10Mixing C++ with Other Languages
Provides guidelines for linking HP aC++ modules with modules written in HP C
and HP FORTRAN 90 on HP systems.
Chapter 11Distributing Your C++ Products
Provides distribution-related information for C++ products. If you choose to
distribute archive libraries or object files, your customer must have purchased HP
aC++. Make sure that your customer has read this distribution information.
Chapter 12Migrating from HP C++ (cfront) to HP aC++
Discusses differences in syntax and functionality that you may need to consider,
when migrating code from HP C++ (cfront) to HP aC++.
Appendix ADiagnostic Messages
Discusses the aCC message catalog and frequently encountered messages. The
aC++ compiler can issue a large variety of diagnostics in response to unexpected
situations or suspicious constructs.
GlossaryContains definitions of terms used in this book, listed alphabetically.
Typographical Conventions
This document uses the following conventions.
audit(5)An HP-UX manpage. In this example, audit is the name and 5 is the section in
the HP-UX Reference respectively. On the Web and on the Instant Information
CD, it may be a hot link to the manpage itself. From the HP-UX command line,
you can enter “man audit” or “man 5 audit” to view the manpage. See
man(1).
Book TitleThe title of a book. On the Web and on the Instant Information CD, it may be
a hot link to the book itself.
KeyCapThe name of a keyboard key.
EmphasisEmphasized text.
BoldStrongly emphasized text.
BoldThe defined use of an important word or phrase.
ComputerOutText displayed by the computer.
UserInputCommands and other text that you type.
CommandA command name or qualified command phrase.
VariableThe name of a variable that you may replace in a command or function or
information in a display that represents several possible values.
[]The contents are optional in syntax. If the contents are a list separated by |,
you must choose one of the items.
{}The contents are required in syntax. If the contents are a list separated by |,
you must choose one of the items.
...The preceding element may be repeated an arbitrary number of times.
|Separates items in a list of choices.
What’s in This Document19
HP-UX Release Name and Release Identifier
Each HP-UX 11i release has an associated release name and release identifier. Theuname(1)
command with the -r option returns the release identifier. This table shows the releases available
for HP-UX 11i.
You can fine additional information about the HP aC++/HP C compiler on the web at http://
www.hp.com/go/hpux-C-Integrity-docs.
20
HP aC++ v A.06.05September 20055
HP aC++ v A.06.00/A.05.60December 20044
HP aC++ v A.05.55.02September 20043
HP aC++ v A.05.55March 20042
HP aC++ v A.05.50August 20031
The following is a list of documents available with this release:
•HP aC++/HP ANSI C Release Notes
This document gives an overview of new command-line options and features in HP aC++ and
HP C compilers for Itanium®-based systems.
•HP C/HP-UX Reference Manual
This manual presents reference information on the C and C++ programming languages.
HP Encourages Your Comments
HP encourages your comments concerning this document. We are truly committed to providing
documentation that meets your needs.
Please send comments to: c++-editor@cup.hp.com
Please include document title, manufacturing part number, and any comment, error found, or
suggestion for improvement that you have about this document.
HP Encourages Your Comments21
1 Getting Started with HP aC++
The information in this document applies to the release of HP aC++ and HP ANSI C compilers
version A.06.28 for the HP-UX 11i v3 operating system.
The HP ANSI C compiler supports ANSI programming language C standard ISO 9899:1999. HP
aC++ compiler supports the ISO/IEC 14882 Standard for the C++ Programming Language (the
international standard for C++).
Version A.06.28 of the HP aC++/HP C compiler provides leading edge support for C++11
standard language features, with complete binary compatibility with earlier releases and -AA
compilation mode.
This chapter discusses the following topics:
•“Components of the Compilation System” (page 22)
•“Compiler Command Syntax and Environmental Variables” (page 24)
•“Files on the aCC Command Line” (page 25)
•“Environment Variables” (page 26)
•“Floating Installation” (page 29)
Components of the Compilation System
The HP aC++ compiling system consists of the following components:
aCCThe aCC driver is the only supported interface to HP aC++ and to the linker for HP aC++
object files.
cccc is the HP-UX C compiler.
c89c89 is the HP-UX ANSI-conforming C89 compiler.
c99c99 is the HP-UX ANSI-conforming C99 compiler.
ecomThe ecom compiler (for A.06.*) compiles the C++ source statements. Preprocessing is
incorporated into the compiler.
ctcomThe ctcom compiler (for A.05.*) compiles the C++ source statements. Preprocessing is
incorporated into the compiler.
The other HP aC++ executable files are:
c++filtc++filt is the name demangler. It implements the name demangling algorithm which
encodes function name, class name, and parameter number and name.
ldld is the linker. It links executables and builds shared libraries.
HP aC++ Runtime Libraries and Header Files:
Standard C++ Library
/usr/lib/hpux32/libstd.so (32-bit shared version)
/usr/lib/hpux32/libstd.a (32-bit archive version)
/usr/lib/hpux64/libstd.so (64-bit shared version)
/usr/lib/hpux64/libstd.a (64-bit archive version)
HP aC++ Runtime Support Library
/usr/lib/hpux##/libCsup.so
/usr/lib/hpux##/libCsup11.so — ISO C++11 standard compliant
/usr/lib/hpux##/libstd.so and libstd_v2.so
/usr/lib/hpux##/libstd_v2.so and librwtool_v2.so
/usr/lib/hpux##/libstream.so
Libraries in /usr/include/hpux##
(where ## is 32 or 64 provided as part of the HP-UX core system)
22Getting Started with HP aC++
Standard C++ Library
/usr/lib/hpux32/libstream.so (32-bit shared version)
/usr/lib/hpux32/libstream.a (32-bit archive version)
/usr/lib/hpux64/libstream.so (64-bit shared version)
/usr/lib/hpux64/libstream.a (64-bit archive version)
Header files for these libraries are located at /opt/aCC/include/.
Using the aCC Command
To invoke the HP aC++ compiling system, use the aCC command at the shell prompt. TheaCC
command invokes a driver program that runs the compiling system according to the filenames and
command line options that you specify.
Compiling a Simple Program
The best way to get started with HP aC++ is to write, compile, and execute a simple program, as
shown in the following example:
#include <iostream.h>
int main()
{
int x,y;
cout << “Enter an integer: “;
cin >> x;
y = x * 2;
cout << “\n” << y <<“ is twice “ << x <<“.\n”;
}
If this program is in the file getting_started.C, compiling and linking the program with the
aCC command produces an executable file named a.out, by default:
$ aCC getting_started.C
Executing the Program
To run this executable file, just enter the name of the file. The following summarizes this process
with the file getting_started.C:
$ a.out
Enter an integer: 7
14 is twice 7.
Debugging Programs
You can use programming and debugging aides.
HP Code Advisor
HP Code Advisor is a code checking tool that can be used to detect programming errors in C/C++
source code. Use "/opt/cadvise/bin/cadvise" to invoke the tool. A brief description is
available with the -help option.
$ /opt/cadvise/bin/cadvise -help
Additional information is available at: http://www.hp.com/go/cadvise/.
HP WDB Debugger
You can also use the HP WDB debugger to debug your C++ programs after compiling your
program with either the -g, the -g0, or the -g1 option.
Example:
The -g0 option enables generation of debug information:
$ aCC -g0 program.C
Components of the Compilation System23
The gdb command runs the HP WDB debugger:
$ gdb a.out
For more information on the HP WDB debugger, refer to “Debugging Options” (page 35).
Accessing Online Example Source Files
Online example source files are located in the directory /opt/aCC/contrib/Examples/RogueWave. These include examples for the Standard C++ Library and for the Tools.h++ Library.
Compiler Command Syntax and Environmental Variables
The aCC command (the driver) invokes the HP aC++ compiling system. The aCC command is
followed by options and files that need to be compiled.
aCC [options] [files]
You must use the aCC command to link your C++ programs and libraries. This ensures that all
libraries and other files needed by the linker are available.
Example:
aCC prog.C
This command compiles the source file prog.C and puts the executable code in the file a.out.
For a complete list of command line options, see Chapter 2: “Command-Line Options” (page 31).
Examples of the aCC Command
Following are some examples of the aCC command:
Compiling and Renaming an Output File
aCC -o prog prog.C
This command compiles prog.C and puts the executable code in the file prog, rather than in the
default file a.out.
Compiling and Debugging
aCC -g prog.C
This command compiles prog.C and includes information that allows you to debug the program
with the HP WDB debugger, wdb.
Compiling Without Linking
aCC -c prog.C
This command compiles prog.C and puts the object code in the file prog.o. It neither links the
object file nor creates an executable file.
Linking Object Files
aCC file1.o file2.o file3.o
This command links the listed object files (file1.o, file2.o, and file3.o) and puts the
executable code in the file a.out.
NOTE:You must use the aCC command to link your HP aC++ programs and libraries. This ensures
that all libraries and other files needed by the linker are available.
Compiling, Optimizing, and Getting Verbose Information
aCC -O -v prog.C
24Getting Started with HP aC++
This command compiles and optimizes prog.C, gives verbose progress reports, and creates an
executable file a.out.
Compiling and Creating a Shared Library
aCC +z -c prog.C
aCC -b -o mylib.sl prog.o
The first line compiles prog.C, creates the object file prog.o, and puts the position-independent
code (PIC) into the object file. The second line creates the shared library mylib.sl, and puts the
executable code into the shared library.
Files on the aCC Command Line
Files containing source or object code to be compiled or linked by HP aC++ can be any of these
files:
•A C++ Source File (.C file)
•Preprocessed Source Files (.i Files)
•Assembly Language Source Files (.s Files)
•Object Files (.o Files)
•Library Files (.a and .so Files)
•“Configuration Files (.conf Files)” (page 26)
Unless you use the -o option to specify otherwise, all files that the aCC compiling system generates
are put in the working directory, even if the source files are from other directories.
C++ Source File (.C file)
You must name the HP aC++ source files with extensions beginning with either .c or .C, possibly
followed by additional characters. If you compile only, for example by using -c, each C++ source
file produces an object file with the same file name prefix as the source file and a .o file name
suffix.
However, if you compile and link a single source file into an executable program in one step, the
.o file is automatically deleted, unless -g is used without +noobjdebug.
NOTE:HP recommends that your source files have .c or .C extensions only, without any
additional characters. While extensions other these are permitted for portability from other systems,
they may not be supported by HP tools and environments.
Preprocessed Source Files (.i Files)
Files with .i extensions are assumed to be preprocessor output files. These files are processed in
the same way as .c or .C files, except that the preprocessor is not run on the .i file before the
file is compiled.
Use the -P or the -E compiler option to preprocess a C++ source file without compiling it.
Assembly Language Source Files (.s Files)
Files with names ending in .s are assumed to be assembly source files. The compiler invokes the
assembler through cc to create .o files from these.
Use the -S option to compile a C++ source file to assembly code and put the assembly code into
a .s file.
Files on the aCC Command Line25
Object Files (.o Files)
Files with .o extensions are assumed to be relocatable object files that have to be included in the
linking. The compiler invokes the linker to link the object files and create an executable file.
Use the -c option to compile a C++ source file into a .o file.
Library Files (.a and .so Files)
Files ending with .a are assumed to be archive libraries. Files ending with .so are assumed to
be shared libraries.
Use the -c and +z options to create object files of Position-Independent Code (PIC) and the -b
option to create a shared library.
Use the -c option to create object files and the ar command to combine the object files into an
archive library.
Configuration Files (.conf Files)
You can configure compiler options on a system-wide basis. The compiler reads the configuration
files:
/var/aCC/share/aCC.conf (aC++), or
/var/ansic/share/cc.conf(ANSI C), if present.
In C-mode, the configuration file defaults to/var/ansic/share/cc.conf, unless overridden
by the environment variable CC_CONFIG..
In C++ mode, the config file defaults to /var/aCC/share/aCC.conf, unless overriden by the
environment variable CXX_CONFIG.
The options in the configuration file can be specified in the same manner as that for CCOPTS and
CXXOPTS, namely:
[options-list-1] [|[options-list-2]]
where options in options-list-1 are applied before the options in the command line, and
options in options-list-2 are applied after the options in the command line.
NOTE:No configuration files are shipped along with aC++, but can be installed by the system
administrator, if required.
The config file options before the "|" character set the defaults for compilations, and the options
after the character override the user’s command line settings.
Environment Variables
This section describes the following environment variables that you can use to control the HP aC++
or HP C compiler:
Exporting the aCC_FULL_PATHNAMES variable causes the compiler to include full path names for
files in compiler messages. This feature is useful in debugging.
aCC_MAXERR Environment Variable
The aCC_MAXERR environment variable allows you to set the maximum number of errors you want
the compiler to report before it terminates compilation. The default is 100.
CXXOPTS Environment Variable
The CXXOPTS environment variable provides a convenient way to include frequently used
command-line options automatically.
Options before the vertical bar (|) are placed before command-line options to aCC. The options
after the vertical bar are placed after any command-line option. Note that the vertical bar must be
delimited by white space.
If you do not use the vertical bar, all options are placed before the command line parameters. Set
the environment variable and the options you want are automatically included each time you
execute the aCC command.
For quick or temporary changes to your build environment, use CXXOPTS instead of editing your
makefiles.
Example:
export CXXOPTS="-v | -lm" ksh/sh notation
setenv CXXOPTS "-v | -lm" csh notation
The above command causes the -v and -l options to be passed to the aCC command each time
you execute it.
When CXXOPTS is set as above, the following two commands are equivalent:
aCC -g prog.C
aCC -v -g prog.C -lm
CCLIBDIR Environment Variable
The CCLIBDIR environment variable causes the aCC command to search for libraries in an alternate
directory before searching in the default directories.
directory is an aCC root directory where you want the HP aC++ driver to search for
subprocesses.
Example:
28Getting Started with HP aC++
export CCROOTDIR=/mnt/CXX2.1
In this example, HP aC++ searches the directories under /mnt/CXX2.1 (/mnt/CXX2.1/bin
and /mnt/CXX2.1/lbin) for subprocesses rather than their respective default directories.
CXX_MAP_FILE Environment Variable
To facilitate easy migration of build environment from a different compiler to HP aC++, an option
mapping support is provided. You can use the option mapping files to map the options in the third
party compilers to HP aC++ equivalents. The mapping file is a text file that defines the mapping
rules. The compiler reads the mapping file and applies the specified replacements to the options
on the command line. This minimizes the need to make Makefile or script changes. The
CXX_MAP_FILE environment variable allows you to change the location of the mapping file.
Syntax:
export CXX_MAP_FILE=file path
Example:
export CXX_MAP_FILE=/home/src/my_option.map
The example specifies that HP aC++ should use mapping file from file path specified using
CXX_MAP_FILE.
Defining the Mapping Rules:
Following is the syntax for defining the rules in the mapping file:
LHS => RHS
where:
•Left Hand Side (LHS) is the third party compiler option.
•Right Hand Side (RHS) is the HP aC++ compiler option
NOTE:Ensure to use a space before and after "=>".
To define rules for options that have arguments, use the $<number> wildcard.
For Example:
$1 for the first argument, and $2 for the second. If the third party compiler option (LHS) does not
match with any HP aC++option, leave the RHS blank.
TMPDIR Environment Variable
The TMPDIR environment variable allows you to change the location of temporary files created
by the compiler. The default directory is /var/tmp.
The above example specifies that HP aC++ should put all temporary files in /mnt/temp.
Floating Installation
More than one version of the HP aC++ compiler can be installed on one system at the same time.
The floating installation feature allows you to install the compiler in any location. You can install
as many compiler versions as required, depending on your system’s resources.
Floating Installation29
HP aC++
By default, HP aC++ is installed under the /opt/aCC directory. In earlier releases, the compiler
driver (aCC) looked for related files in subdirectories of the /opt/aCC directory. This prevented
installation of more than one version of HP aC++ on the same system at the same time.
Only files in /opt/aCC are affected by floating installation. Regardless of the HP aC++ driver
you use, the compiler still uses the libraries, linker, and other files located in /usr/lib and /usr/ccs.
Floating installation is designed to help facilitate in-house development. You must not ship libraries
in non-standard places, because explicit runtime library specifications and linker options are
required.
You can use the __HP_aCC predefined macro to determine which version is being run.
HP C
You can use the __HP_cc predefined macro to determine which version is being run.
NOTE:Do not use floating installation with the following:
•CCROOTDIR environment variable
•-tc,name command line option
Setting up Floating Installation
You may want to install the most recent compiler version and keep the prior version on one system.
If there are problems with the most recent version, you can easily switch to the prior one. Following
is an example of how to set up the floating installation feature for this purpose. Assume that your
system will have two versions of the compiler, both floating install enabled. In this case, A.05.50
is the prior version, and A.05.60 or A.06.00 is the more recent version.
To setup floating installation, complete the following steps:
1.Copy the prior version to another directory.
cp -rp /opt/aCC /opt/aCC.05.55
2.Use swinstall to install the new version (A.06.00 or A.05.60 in this case).
30Getting Started with HP aC++
2 Command-Line Options
You can specify command-line options to the aCC command. They allow you to override the default
actions of the compiler. Each option begins with either a - or a + sign. Any number of options can
be interspersed anywhere in the aCC command and they are typically separated by blanks. Unless
specified otherwise, all options are supported by C and C++ compilers.
Default options can be set using option configuration files. See “Configuration Files (.conf Files)”
(page 26).
This chapter discusses the following command-line options:
The following options allow you to control the kind of code that the compiler generates:
•-c
•+DOosname
•+DDdata_model
•+DSmodel
•-S
-c
You can use the -c option to compile one or more source files without entering the linking phase.
When compiled, the compiler produces an object file (a file ending with .o) for each source file
(a file ending with .c, .C, .s, or .i). Note that you must link object files before they can be
executed.
Example:
aCC -c sub.C prog.C
In this example, the compiler compiles sub.C and prog.C and puts the relocatable object code
in the files, sub.o and prog.o, respectively.
+DOosname
The +DOosname option sets the target operating system for the compiler, and is intended for
enabling optimizations that are not backward compatible.
For instance, the 11.23 compiler introduces new optimized math library functions that require
library support not available in prior operating systems. +DO can be used at any level of
optimization. The default value for osname is the operating system version on which the compiler
is invoked.
The syntax for this option is +DOosname, where osname is either 11.20, 11.22 or 11.23.
Example:
The following example generates code for the HP-UX 11.22 (or later) operating system. Binary
incompatible features introduced in later OS versions are inhibited.
aCC +DO11.22 +O3 app.C
+DDdata_model
The +DDdata_model option specifies the data model for the compiler.
data_model can be one of the following:
•32 (This value generates ILP32 code and is the default.)
•64 (This value generates LP64 code.)
This option specifies the data model for the compiler. Table 2 lists the differences between the two
data models.
Table 2 ILP32 Data Model and LP64 Data Model
The size of an int, long, or pointer data type is
32-bits.
The preprocessor predefined macro _ILP32 is defined.
32Command-Line Options
LP64 Data ModelILP32 Data Model
The size of an int data type is 32-bits. The size of a long
or pointer data type is 64-bits.
The preprocessor predefined macros__LP64__ and _LP64
are defined.
Examples:
The following command generates code for the 64-bit data model:
aCC +DD64 app.C
The following command generates code for the 32-bit data model:
aCC app.C
+DSmodel
The +DSmodel option performs instruction scheduling for a particular implementation of the
Itanium®-based architecture.
model can be one of the following values.
blendedTune to run reasonably well on multiple implementations. As old implementation
itanium
become less important and new implementations are added, the behavior with
this value will change accordingly.
Tune for the Itanium® processor.
itanium2
mckinley
montecito
poulson
nativeTune for the processor on which the compiler is running.
The default is blended. Object code with scheduling tuned for a particular model will execute on
other HP-UX systems, although possibly less efficiently.
Tune for the Itanium2® processor.
See itanium2® .
Tune for the Montecito® processor.
Tune for the Poulson® processor.
Using +DS to Specify Instruction Scheduling
Instruction scheduling is different on different implementations of Itanium®-based architectures.
You can improve performance on a particular model or processor of the HP-UX system by requesting
the compiler to use instruction scheduling tuned to that particular model or processor. Using
scheduling for one model or processor does not prevent your program from executing on another
model or processor.
If you plan to run your program on the same system where you are compiling, you do not need
to use the +DS option. The compiler generates code tuned for your system.
If you plan to run your program on a particular model of the HP-UX system, and that model is
different from the one where you compile your program, use +DSmodel with either the model
number of the target system or the processor name of the target system.
Compiling in Networked Environments
When compiles are performed using diskless workstations or NFS-mounted file systems, it is
important that the default code generation and scheduling are based on the local host processor.
The system model numbers of the hosts where the source or object files reside do not affect the
default code generation and scheduling.
-S
The -S option compiles a program and logs the assembly language output in a corresponding file
with a .s suffix. The -S option is only for displaying the assembler code. The generated code is
not intended to be used as input to the assembler (as).
Example:
Options to Control Code Generation33
The following command compiles prog.C to assembly code rather than to object code, and puts
the assembly code in the file prog.s.
aCC -S prog.C
Data Alignment and Storage
This section describes default data storage allocation and alignment for HP compiler data types.
Data storage refers to the size of data types, such as bool, short, int, float, and char*.
Data alignment refers to the way the HP compiler aligns data structures in memory. Data type
alignment and storage differences can cause problems when moving data between systems that
have different alignment and storage schemes. These differences become apparent when a structure
is exchanged between systems using files or inter-process communication. In addition, misaligned
data addresses can cause bus errors when an attempt is made to dereference the address.
For information on unaligned data access, See “Handling Unaligned Data” (page 101).
Table 3 lists the size and alignment of the HP compiler data types:
Table 3 Size and Alignment of HP Compiler Data Types
char
AlignmentSize (in bytes)Data Type
1-byte1bool
11char, unsigned char, signed
short
44wchar_t
22short, unsigned short, signed
44int, unsigned int
4*4*long, unsigned long
44float
1616__float80
8**16__float128
44_Decimal32
88_Decimal64
1616_Decimal128
88double
8**16long double
88long long, unsigned long long
44enum
Alignment of array element typeSize of array element typearrays
* In 64-bit mode, long, unsigned long, and pointer data types are 8 bytes long and 8-byte aligned.
** In 64-bit mode, long double is 16-byte aligned.
34Command-Line Options
1-, 2-, 4-, 8-, or 16-byte***struct
1-, 2-, 4-, 8-, or 16-byte***union
Alignment of declared typeSize of declared typebit-fields
4*4*pointer
Table 3 Size and Alignment of HP Compiler Data Types (continued)
*** struct and union alignment are same and follow strict alignment of any member. Padding is done to a multiple
of the alignment size.
-fshort-enums
cc -Agcc -Wc,--fshort-enums foo.c
aCC -Ag++ -Wc,--fshort-enums foo.c
The -fshort-enums option is used with the -Agcc or -Ag++ options to cause each enum type
to be represented using the smallest integer type that is capable of representing all values of the
enum type. Because it changes the representation of types, the code generated is not binary
compatible with code compiled without the option. The primary use of this option is for compatibility
with gcc, but it can provide performance improvement to applications that can accept the binary
incompatibility.
+unum
+unum
The +unum option allows pointers to access non-natively aligned data. This option alters the way
that the compiler accesses dereferenced data. Use of this option may reduce the efficiency of
generated code. Specify num as 1, 2, or 4, as follows:
1 - Assume single byte alignment. Dereferences are performed with a series of single-byte loads
and stores.
2 - Dereferences are performed with a series of two-byte loads and stores.
4 - Dereferences are performed with a series of four-byte loads and stores.
Example:
aCC +u1 app.C
AlignmentSize (in bytes)Data Type
Debugging Options
Debugging options enable you to use the HP WDB debugger.
Information on HP WDB is available at this location: http://www.hp.com/go/wdb
+d
The +d option prevents the expansion of inline functions. It is useful when you debug code because
breakpoints cannot be set at inline functions. Using the +d option disables all inlining. It is mapped
to the +inline_level 0 option.
+expand_types_in_diag
The +expand_types_in_diag option expands typedefs in diagnostics so that both the original
and final types are present.
-g
The -g option causes the compiler to generate minimal information for the debugger. It uses an
algorithm that attempts to reduce duplication of debug information.
To suppress expansion of inline functions, use the +d option.
-g0
The -g0 option causes the compiler to generate full debug information for the debugger.
Debugging Options35
To suppress expansion of inline functions, use the +d option.
-g1
Like the -g option, the -g1 option causes the compiler to generate minimal information for the
debugger. It uses an algorithm that attempts to reduce duplication of debug information. To suppress
expansion of inline functions, use the +d option.
Differences Between -g, -g0, and -g1 Options
The -g, -g0, and -g1 options generate debug information. The difference is that the -g0 option
emits full debug information about every class referenced in a file, which can result in some
redundant information.
The -g and -g1 options emit a subset of this debug information, thereby decreasing the size of
your object file. If you compile your entire application with -g or -g1, no debugger functionality
is lost.
NOTE:If you compile part of an application with -g or -g1 and part with debug off, (that is,
with neither the -g, the -g0, nor the -g1 option) the resulting executable may not contain complete
debug information. You will still be able to run the executable, but in the debugger, some classes
may appear to have no members.
When to use -g, -g0, and -g1
Use -g or -g1 when you are compiling your entire application with debug on and your application
is large, for example, greater than 1 MB.
Use -g0 when either of the following is true:
•You are compiling only a portion of your application with debug on, for example, a subset
of the files in your application.
•You are compiling your entire application with debug on and your application is not very
large, for example, less than 1 MB.
-g, -g1 Algorithm
In general, the compiler looks for the first non-inline, non-pure (non-zero) virtual function in order
to emit debug information for a class.If there are no virtual member functions, the compiler looks
for the first non-inline member function.
If there are no non-inline member functions, debug information is always generated.
A problem occurs if all functions are inline; in this case, no debug information is generated.
+macro_debug
This option controls the emission of macro debug information into the object file.
Set +macro_debug to one of the following required options:
refEmits debug information only for referenced macros. This is the default for -g, -g1, or
-g0.
allEmits debug information for all macros. This option can cause a significant increase in
object file size.
noneDoes not emit any macro debug information.
One of the -g options (-g, -g0, or -g1) must be used to enable the +macro_debug option.
36Command-Line Options
+[no]objdebug
The +objdebug option generates debug information in object files and not in the executable. The
HP WDB debugger then reads the object files to construct debugging information; they must be
present when debugging.
The +noobjdebug option generates debug information in object files which the linker places into
the executable. The HP WDB debugger then reads the executable to construct debugging
information.
NOTE:With +objdebug, the object files or archive libraries must not be removed.
+objdebug is the default at link time and at compile time. If +noobjdebug is used at link time,
all debug information goes into the executable, even if some objects were compiled with
+objdebug.
If +objdebug is used at compile time, extra debug information is placed into each object file to
help the debugger locate the object file and to quickly find global types and constants.
Usage:
Use +objdebug option to enable faster links and smaller executable file sizes for large applications,
rather than +noobjdebug where debug information is written to the executable.
Use +noobjdebug with the -g, -g0, or -g1 option when using +ild.
+pathtrace
+pathtrace[=kind]
The +pathtrace option provides a mechanism to record program execution control flow into
global and/or local path tables. The saved information can be used by the HP WDB debugger to
assist with crash path recovery from the core file, or to assist when debugging the program by
showing the executed branches.
Currently only if, else, switch-case-default, and try-catch execution paths are recorded
in the path table. If there is no condition statement inside a for, while, or do-while loop, then
no excution path is recorded.
Usage:
The defined values for kind are:
localGenerates a local path table and records basic block-execution
information in it at runtime.
globalGenerates a global path table and records basic block-execution
information in it at runtime.
The global path table is a fixed size. The default size of the table is
8K items. Each basic block that is executed is recorded as an item of
path-trace information in the table. Each thread has its own table, and
when the table is full, the runtime system wraps the path table back to
the beginning of the table.
The table size can be configured at runtime using the environment
variable HP_PATHTRACE_CONFIG, which also lets you specify a file
to be used for dumping full tables and the dumping format, before
wrapping around or at thread/program termination.
The syntax of the environment variable HP_PATHTRACE_CONFIG is:
•TABLE_SIZE specifies the size, expressed as the number of items
(nnn), of the global path table.
•FILE specifies the dumping output filename to use when the global
path table is full.
•FORMAT specifies the dumping format in either "binary or
human-readable "text".
global_fixed_sizeGenerates a fixed-size (65536 items) global path table and records
basic block-execution information in it at runtime.
This form differs from+pathtrace=global because the size of the
table cannot be configured at runtime, and the contents cannot be
dumped to a file. The fixed-size global path table has better runtime
performance than the configurable global path table. The performance
difference varies depending on the optimization level and how the
program is written.
noneDisables generation of both the global and local path tables.
The values can be combined by joining them with a colon. For example:
+pathtrace=global:local
The global_fixed_size and global values are mutually exclusive. If more than one of them
are specified on the command line, the last one takes precedence. The same is true for the none
value.
+pathtrace with no values is equivalent to +pathtrace=global_fixed_size:local.
The use of this option and the -mt option must be consistent for all compilation and link steps.
That means if -mt is used with +pathtrace at compile time, it should also be used at link time;
if -mt is not used with +pathtrace at compile time, it should not be used at link time. Otherwise,
a link-time error can occur.
Error Handling
Use the following options to control how potential errors in your code are detected and handled.
You can also use the cadvise report feature of the HP Code Advisor tool to help analyze
compiler errors and warnings.
+p
The +p option disallows all anachronistic constructs.
Ordinarily, the compiler gives warnings about anachronistic constructs. Using the +p option, the
compiler gives errors for anachronistic constructs.
Example:
The following command compiles file.C and gives errors for all anachronistic constructs rather
than just giving warnings.
aCC +p file.C
-w
The -w option disables all warnings except those that are explicitly enabled with a +Wwargs
option or a subsequent +w-prefix option. By default, the compiler reports all errors and warnings.
HP recommends against using the -w option. In addition to disabling messages currently output
by the compiler, it will also disable any new messages added to the compiler in the future that
could identify problem areas in user code. HP recommends using the +Wargs option to disable a
message. Although it can often take a long list of +Warg options to disable all desired warnings,
38Command-Line Options
+w
+wn
this list can be included in an options file and referenced using the +opts option to avoid listing
them all directly on the command line.
Example:
The following command compiles file.C and reports errors but does not report any warnings.
aCC -w file.C
The +w option warns you about all questionable constructs and gives pedantic warnings. +w
enables all checks except for the +wsecurity, +wendian, +wperfadvice, and+wlock
warnings. Those need to be enabled explicitly if needed. The default is to warn only about constructs
that are almost certainly problems.
For example, this option warns you when calls to inline functions cannot be expanded inline.
The following command compiles file.C and warns about both questionable and problematic
constructs:
aCC +w file.C
NOTE:This option is equivalent to the +w1 option of legacy HP C.
The +wn option specifies the level of the warnings messages.
+w{1|2|3}
The value of n can be one of the following:
1All warnings are issued. This includes low level warnings that may not indicate anything wrong
with the program.
2Only warnings indicating that code generation might be affected are issued. This is equivalent
to the compiler default without the -w options.
3No warnings are issued. This is equivalent to the -w option. This option is the same as -W c
and-wn.
+Wargs
+Warg1[,arg2,..argn]
The +Wargs option selectively suppresses any specified warning messages.
Arguments arg1 through argn are valid compiler warning message numbers.
Example:
aCC +W600 app.C
+Wcontext_limit
+Wcontext_limit=num
The +Wcontext_limi option limits the number of instantiation contexts output by the compiler
for diagnostics involving template instantiations. At most num outermost contexts and num innermost
contexts are shown. If there are more than 2*num relevant contexts, the additional contexts are
omitted.
Omitted contexts are replaced by a single line separating the outermost num contexts from the
innermost num contexts, and indicating the number of contexts omitted. The default value for num
is 5. A value of 0 removes the limit.
Error Handling39
+We
+We
The +We option interprets all warning and future error messages as errors.
Alternatively you can also use +We[arg1,...argn] option, where arg is a valid compiler
warning message number. Use of arg is optional.
+Weargs
+Wearg1[,arg2,..,argn]
The +Weargs option selectively interprets any specified warning or future error messages as errors.
arg1 through argn are valid compiler warning message numbers.
Example:
aCC +We 600,829 app.C
+Wv
+Wv[d1,d2,..,dn]
The +Wv option displays the description for diagnostic message numbers d1 through dn.
Specifying this option causes the compiler to emit the descriptive text for the specified dianostics
to stderr. This option must not be used with any other compiler options.
If the description for a diagnostic is not available, the compiler emits only the diagnostic with a
note that the description is not available.
+Wwargs
+Wwarg1[,arg2,..,argn]
The +Wwargs option selectively treats compiler remarks or discretionary errors as warnings. arg1
through argn are valid compiler message numbers. Conflicts between +W, +Ww, and +We are
resolved based on their severity. +We is the highest and +W is the lowest.
+wlint
This option enables several warnings in the compiler that provide lint like functionality. Checks are
made for memory leaks, out-of-scope memory access, null pointer dereference, and out-of-bounds
access. These compile time diagnostics can be very useful in detecting potential problems in the
source code. To disable a specific warning introduced by +wlint, a +Wargs option can be used
after the +wlint option.
NOTE:The +wlint option is only supported on Itanium-based systems.
+Wmacro
+Wmacro:MACRONAME:d1,d2,...,dn
The +Wmacro option disables warning diagnostics d1,d2,...,dn in the expansion of macro
MACRONAME. If -1 is given as the warning number, then all warnings are suppressed. This option
is not applicable to warning numbers greater than 20000. +Wmacro gets higher priority than the
other diagnostic-control command-line options that are applicable to the whole source. Diagnostic
control pragmas take priority based on where they are placed.
+wperfadvice
+wperfadvice[={1|2|3|4}]
The +wperfadvice option enables performance advisory messages.
40Command-Line Options
The optional level 1, 2, 3,or 4 controls how verbosely the performance advisory messages are
emitted. The higher the level, the more messages generated. Level 1 emits only the most important
messages, while level 4 emits all the messages.
If the optional level is not specified, it defaults to 2.
+wsecurity
The +wsecurity option enables compile-time diagnostics for potential security violations. Warnings
are emitted for cases where untrusted (tainted) data may reach a critical reference point in the
program. This is based on cross-module analysis performed by the compiler. Hence the
+wsecurity option implicitly enables a limited form of cross-module analysis, even if -ipo or
+O4 options are not specified. This may lead to a significant increase in the compile time compared
to a build without the +wsecurity option. Using this option may result in the compiler invoking
optimizations other than those that are part of the user-specified optimization level. If +wsecurity
is used in addition to -ipo or +O4, the generated code is not affected and the compile time does
not significantly increase.
This option can optionally take an argument to control how verbosely the security messages are
emitted:
+wsecurity[={1|2|3|4}]
The higher the check level, the more warnings can be generated. Note that this may also generate
more false positives.
The default level is 2.
Exception Handling
By default, exception handling is enabled. To turn off exception handling, use the following option.
+noeh
+noeh
The +noeh option disables exception handling. With exception handling disabled, the keywords
throw and try generate an error.Mixing code compiled with and without +noeh may give undesired results.
Example:
aCC +noeh progex.C
This command compiles and links progex.C, which does not use exception handling.
See Chapter 8: “Exception Handling” (page 161) for more information.
Extensions to the Language
These options support extensions to the C++ language.
-ext
-ext
Exception Handling41
Specifying -ext, enables the following HP aC++ extensions to the C++ standard:
•64-bit integer data type support for:
long long (signed 64-bit integer)◦
◦unsigned long long (unsigned 64-bit integer)
•Use this option to declare 64-bit integer literals and for input and output of 64-bit integers.
•#assert, #unassert preprocessor directives, which allow you to set a predicate name or
predicate name and token to be tested with a #if directive.
When this option is used with -AC89 or -AC99, it defines the following macros:
•-D__STDC_EXT__
•-D_HPUX_SOURCE (unless -Aa is used)
NOTE:When using -ext, specify it at both compile and link time. For example:
aCC -ext foo.C
compiles foo.C which contains a long long declaration.
#include <iostream.h>
int main(){
long long ll = 1;
cout << ll << endl;
}
+e
The +e option is equivalent to the -ext option.
Floating-Point Processing Options
The following command-line options are used for floating-point processing.
+O[no]cxlimitedrange
+O[no]cxlimitedrange
The +O[no]cxlimitedrange option enables [disables] the specific block of codes with the usual
mathematical formulas. This option is equivalent to adding the pragma:
#pragma STDC CX_LIMITED_RANGE
The default is +Onocxlimitedrange.
+O[no]fenvaccess
+O[no]fenvaccess
The +O[no]fenvaccess option provides a means to inform the compiler when a program might
access the floating-point environment to test flags or run under non-default modes.
Use of the +Onofenvaccess option allows certain optimizations that could subvert flag tests and
mode changes such as global common subexpression elimination, code motion, and constant
folding. This option is equivalent to adding #pragma STDC FENV_ACCESS ON at the beginning
of each source file submitted for compilation.
The default is +Onofenvaccess.
42Command-Line Options
-fpeval
-fpeval=precision
The -fpeval option specifies the minimum precision to use for floating-point expression evaluation.
This option does not affect the precision of parameters, return types, or assignments.
The defined values for precision are:
floatEvaluates floating-point expressions and constants in their semantic type.
doubleEvaluates float operations and constants using the range and precision of double,
extendedUtilizes hardware support of these floating-point registers for optimum speed in
The default is -fpeval=float.
-fpevaldec
-fpevaldec=precision
The -fpevaldec option specifies the minimum precision to use for decimal floating-point
expression evaluation. The possible values for precision are _Decimal32, _Decimal64, and
_Decimal128. This option does not affect the precision of parameters, return types, or assignments.
and evaluates all other floating-point expressions and constants in their semantic
type.
floating-point computations. Evaluates float and double constants and expressions
using the range and precision of the extended type, and evaluates all other
floating-point expressions in their semantic type. Though this option provides greater
precision than double, it does not provide greater speed than double or float.
The default is -fpevaldec=_Decimal32.
-[no]fpwidetypes
-[no]fpwidetypes
The -[no]fpwidetypes option enables [disables] extended and quad floating-point data
types. quad is equivalent to long double. This option also enables __float80 prototypes.
The compiler defines _FPWIDETYPES when -fpwidetypes is in effect.
The default is -nofpwidetypes.
+decfp
The +decfp option enables full decimal floating-point functionality according to the ISO/IEC C
draft Technical Report (http://www.open-std.org/jtc1/sc22/wg14/www/docs/
n1312.pdf )
Decimal floating-point is also supported in C++ compilation mode.
For more information on using Decimal FP, see the HP aC++/HP ANSI C Release Notes section
"Decimal floating-point arithmetic supported" under "New Features in the A.06.20 Release."
+FP
+FP[flags]
The +FP option specifies how the runtime environment for floating-point operations should be
initialized at program startup and used at link time. The default is that all trapping behaviors are
disabled.
The following flags are supported. Uppercase enables the flag, lowercase disables the flag.
Floating-Point Processing Options43
Table 4 Options for +FP[flags]
To dynamically change these settings at runtime, see fesetenv(3M).
+FPmode
+FPmode specifies how the run-time environment for floating-point operations should be initialized
at program start up. By default, modes are as specified in the IEEE floating-point standard: all traps
disabled, gradual underflow, and rounding to nearest. See ld(1) for specific values of mode.
To dynamically change these settings at run time, refer to fenv(5), fesettrapenable(3M),
and fesetround(3M).
+O[no]libmerrno
DescriptionFlag
Trap on invalid floating-point operations.V (v)
Trap on divide by zero.Z (z)
Trap on floating-point overflow.O (o)
Trap on floating-point underflow.U (u)
Trap on floating-point operations that produce inexact results.I (i)
Enable sudden underflow (flush to zero) of denormalized values.D (d)
+O[no]libmerrno
Description:
The +O[no]libmerrno option enables [disables] support for errno in libm functions. The
default is +Onolibmerrno for C++, c99, or –AC99.
In C-mode, the default is +Olibmerrno with -Aa option.
+Oprefetch_latency
+Oprefetch_latency=cycles
The +Oprefetch_latency option applies to loops for which the compiler generates data prefetch
instructions. cycles represents the number of cycles for a data cache miss. For a given loop, the
compiler divides cycles by the estimated loop length to arrive at the number of loop iterations
for which to generate advanced prefetches.
cycles must be in the range of 0 to 10000. A value of 0 instructs the compiler to use the default
value, which is 480 cycles for loops containing floating-point accesses and 150 cycles for loops
that do not contain any floating-point accesses.
For tuning purposes, it is recommended that users measure their application’s performance using
a few different prefetch latency settings to determine the optimal value. Some floating-point codes
may benefit by increasing the distance to 960. Parallel applications frequently benefit from a
shorter prefetch distance of 150.
+O[no]preserved_fpregs
+O[no]preserved_fpregs
The +O[no]preserved_fprefs option specifies whether the compiler is allowed [not allowed]
to make use of the preserved subset of the floating-point register file as defined by the Itanium
runtime architecture.
The default is +Opreserved_fpregs.
44Command-Line Options
+O[no]rotating_fpregs
+O[no]rotating_fpregs
The +O[no]rotating_fpregs option specifies whether the compiler is allowed [not allowed]
to make use of the rotating subset of the floating-point register file.
The default is +Orotating_fpregs.
+O[no]sumreduction
+O[no]sumreduction
This option enables [disables] sum reduction optimization. It allows the compiler to compute partial
sums to allow faster computations. It is not technically legal to do this in C or C++ because of
floating-point accuracy issues. This option is useful if an application cannot use the +Onofltacc
option but wants sum reduction to be performed.
When sum reduction optimization is enabled, the compiler may evaluate intermediate partial sums
of float or double precision terms using (wider) extended precision, which reduces variation in the
result caused by different optimization strategies and generally produces a more accurate result.
Header File Options
Following are the command-line options you can use for header files:
-H
cc -H file
The -H option causes HP aC++/HP C to print the order and hierarchy of included files. The -H
option dumps the include heirarchy to stderr so that the preprocessed compiler output indicates
the include file nesting.
+hdr_create
aCC progname -c +hdr_create headername
This option extracts the header from a program file and saves it as a precompiled header file.
Example:
aCC ApplicTemplate.C -c +hdr_create ApplicHeader
+hdr_use
aCC progname +hdr_use headerfile -c
This option adds a precompiled header file to a program when the program is compiled.
Example:
aCC Applic.C +hdr_use ApplicHeader -c
-I directory
-I directory
directory is the HP-UX directory where the compiler looks for header files.During the compile phase, this option adds directory to the directories to be searched for
#include files during preprocessing. During the link phase, this option adds directory to the
directories to be searched for #include files by the link-time template processor.
For #include files that are enclosed in double quotes (" ") within a source file and do not begin
with a /, the preprocessor searches in the following order:
Header File Options45
-I-
1.The directory of the source file containing the #include.
2.The directory named in the -I option.
3.The standard include directories /opt/aCC/include and /usr/include.
For #include files that are enclosed in angle brackets (< >), the preprocessor searches in the
following order:
1.The directory named in the -I option.
2.The standard include directories /opt/aCC/include and /usr/include.
NOTE:The current directory is not searched when angle brackets (< >) are used with #include.
Example:
The following example directs the compiler to search in the directory include for #include
files.
aCC -I include file.C
[-Idirs] -I- [-Idirs]
[-Idirs] indicates an optional list of -Idirectory specifications in which a directory name
cannot begin with a hyphen (-) character.
The -I- option allows you to override the default -Idirectory search-path. This feature is called
view-pathing. Specifying -I- serves two purposes:
1.It changes the compiler’s search-path for quote enclosed (" ") file names in a #include
directive to the following order:
a.The directory named in the -Ioption.
b.The standard include directories /opt/aCC/include* and /usr/include.
The preprocessor does not search the directory of the including file.
2.It separates the search-path list for quoted and angle-bracketed include files.
Angle-bracket enclosed file names in a #include directive are searched for only in the
-Idirectories specified after -I- on the command-line. Quoted include files are searched for
in the directories that both precede and follow the -I- option.
The standard aCC include directories (/usr/include and /opt/aCC/include*) are always
searched last for both types of include files.
Usage:
View-pathing can be particularly valuable for medium to large sized projects. For example, imagine
that a project comprises two sets of directories. One set contains development versions of some of
the headers that the programmer currently modifies. A mirror set contains the official sources.
Without view-pathing, there is no way to completely replace the default -Idirectory search-path
with one customized specifically for project development.
With view-pathing, you can designate and separate official directories from development directories
and enforce an unconventional search-path order. For quote enclosed headers, the preprocessor
can include any header files located in development directories and, in the absence of these,
include headers located in the official directories.
If -I- is not specified, view-pathing is turned off. This is the default.
Examples:
With view-pathing off, the following example obtains all the quoted include files from dir1 only
if they are not found in the directory of a.C and from dir2 only if they are not found in dir1.
Finally, if necessary, the standard include directories are searched. Angle-bracketed include files
are searched for in dir1, then dir2, followed by the standard include directories.
46Command-Line Options
aCC -Idir1 -Idir2 -c a.C
With view-pathing on, the following example searches for quoted include files in dir1 first and
dir2 next, followed by the standard include directories, ignoring the directory of a.C.Angle-bracketed includes are searched for in dir2 first, followed by the standard include directories.
aCC -Idir1 -I- -Idir2 -c a.C
NOTE:Some of the compiler’s header files are included using double quotes. Since the -I-
option redefines the search order of such includes, if any standard headers are used, it is your
responsibility to supply the standard include directories (/opt/aCC/include* and /usr/include) in the correct order in your -I- command line.
For example, when using -I- on the aCC command line, any specified -I directory containing
a quoted include file having the same name as an HP-UX system header file, may cause the following
possible conflict.
In general, if your application includes no header having the same name as an HP-UX system
header, there is no chance of a conflict.
Suppose you are compiling program a.C with view-pathing on. a.C includes the file a.out.h
which is a system header in /usr/include:
aCC -IDevelopmentDir -I- -IOfficialDir a.C
If a.C contains:
// This is the file a.C
#include <a.out.h>
// ...
When a.out.h is preprocessed from the /usr/include directory, it includes other files that
are quote included (like #include "filehdr.h").
Since with view-pathing, quote enclosed headers are not searched for in the including file’s directory,
filehdr.h which is included by a.out.h will not be searched for in a.out.h’s directory
(/usr/include).
Instead, for the above command line, the system header is first searched for in DevelopmentDir,
then in OfficialDir and if it is found in neither, it is finally searched for in the standard include
directories, /opt/aCC/include* and /usr/include, in the latter of which it will be found.
However, if you have a file named filehdr.h in DevelopmentDir or OfficialDir, that file
(the wrong file) will be found.
Online Help Option
Use the +help option to view the HP aC++ Online Help.
+help
+help
The +help option invokes the initial menu window of this HP aC++ Online Help.
If +help is used on any command line, the compiler displays the HP aC++ Online Help with the
default web browser and then processes any other arguments.
If $DISPLAY is set, the default web browser is used. If the display variable is not set, a message
is displayed. Set your $DISPLAY variable as follows:
To use a browser other than the default, first set the BROWSER environment variable to the alternate
browser’s location:
export BROWSER=AlternateBrowserLocation
To invoke the online guide, use the command:
aCC +help
Inlining Options
These options allow you to specify the amount of source code inlining done by HP aC++.
+inline_level num
+inline_level num
The +inline_level option controls how C/C++ inlining hints influence aCC or cc. Such inlining
happens in addition to functions that are explicitly tagged with the inline keyword. (For C89,
use the __inline keyword). This option controls functions declared with the inline keyword
or within the class declaration, and is effective at all optimization levels.
NOTE:The +d and +inline_level 0 options turn off all inlining, including implicit inlining.
The format for
numisN[.n
], where
num
is either an integral value from 0 to 9, or a value with a
single decimal place from 0.0 to 9.0, as described in the following table:
num
1
2
9
Description
No inlining is done (same effect as the +d option).0
Only functions marked with the inline keyword or implied by the language to be inline are
considered for inlining.
This is the default for C++ at +O1.
Increasingly makes inliner more aggressive below 2.0.1.0 < num < 2.0
Provides more inlining than level 1. This is the default level at optimization levels +O2, +O3, and
+O4.
Increasing levels of inliner aggressiveness.2.0 < num < 9.0
Attempts to inline all functions other than recursive functions or those with a variable number of
arguments.
The default level depends on +Olevel as shown in the following table:
numlevel
10
The +O[no]inline option controls the high-level optimizer that recognizes other opportunities
in the same source file (+O3) or amongst all source files (+O4). For example,
aCC +inline_level 3 app.C
48Command-Line Options
11
22
23
24
Library Options
Library options allow you to create, use, and manipulate libraries.
-b
-b
The -b option creates a shared library rather than an executable file.
Example:
The following command links utils.o and creates the shared library utils.so.
aCC -b utils.o -o utils.so
For more information on shared libraries, see “Creating and Using Libraries” (page 175).
-dynamic
-dynamic
The -dynamic option produces dynamically bound executables. See “-minshared” (page 50) for
partially statically bound executables.
The default is -dynamic.
-exec
-exec
-lname
The -exec option indicates that any object file created will be used to create an executable file.
Constants with a protected or hidden export class are placed in the read-only data section. This
option also implies -Bprotected_def. It makes all defined functions and data (even tentatively
defined data) protected by default (unless otherwise specified by another binding option or pragma).
-lname
The name value forms part of the name of a library the linker searches for when looking for routines
called by your program.
The -lname option causes the linker to search one of the following default libraries, if they exist,
in an attempt to resolve unresolved external references:
•/usr/lib/lib/hpux32/name.so
•/usr/lib/lib/hpux32/name.a
•/opt/langtools/lib/hpux32lib/name.so
•/opt/langtools/lib/hpux64lib/name.a
Whether it searches the shared library (.so) or the archive library (.a) depends on the value of
the -a linker option or the -minshared compiler option.
NOTE:Because a library is searched when its name is encountered, placement of a -l is
significant. If a file contains an unresolved external reference, the library containing the definition
must be placed after the file on the command line. For details refer to the description of ld in the
HP-UX Reference Manual or the ld(1) manpage for more information.
Example:
aCC file.o -lnumeric
This command directs the linker to link file.o and (by default) search the library /usr/lib/
hpux32/libnumeric.so.
Library Options49
-L directory
-L directory
The directory parameter is the HP-UX directory where you want the linker to search for libraries
your program uses before searching the default directories.
The -L directory option causes the linker to search for libraries in directory in addition to using
the default search path.
See -lname option for default search path.
The -L option must precede any -lname option entry on the command line; otherwise -L is
ignored. This option is passed directly to the linker.
Example:
The following example compiles and links prog.C and directs the linker to search the directories
and /project/libs for any libraries that prog.C uses (in this case, mylib1 and mylib2).
aCC -L/project/libs prog.C -lmylib1 -lmylib2
-minshared
-minshared
The -minshared option indicates that the result of the current compilation is going into an
executable file that will make minimal use of shared libraries. This option is equivalent to -exec
-Bprotected.
+nostl
+nostl
By eliminating references to the standard header files and libraries bundled with HP aC++, the
+nostl option allows experienced users full control over the header files and libraries used in
compilation and linking of their applications, without potential complications that arise in mixing
different libraries.
NOTE:Complete understanding of the linking process and the behavior of the actual (third party)
libraries linked with the application is essential to avoid link or runtime failures.
For more information on shared libraries, see “Creating and Using Libraries” (page 175).
+Onolibcalls=
+Onolibcalls=function1,function2,...
This option allows you to turn off libcall optimizations (inlining or replacement) for calls to the listed
functions. This option overrides system header files.
Linker Options
You can specify the following linker options on the compiler command line:
-e epsym
-e epsym
Using the -e epsym option sets the default entry point address for the output file to be the same
as the symbol epsym. This option only applies to executable files. It does not work if epsym=xec.
-n
-n
The -n option causes the program file produced by the linker to be marked as sharable.
50Command-Line Options
For details and system defaults, refer to the description of ld in the HP-UX Reference Manual or theld(1) manpage for more information.
-N
-N
The -N option causes the program file produced by the linker to be marked as unsharable.
For details and system defaults, refer to the description of ld in the HP-UX Reference Manual or the
ld(1) manpage for more information.
+O[no]dynopt
+O[no]dynopt
Supported only on HP-UX 11.31 systems, the +O[no]dynopt option enables [disables] dynamic
optimization for the output file. Both forms of this option change the default setting, which allows
the run-time environment to enable or disable dynamic optimization according to a system-wide
default. This option applies only to executable files and shared libraries, if the run-time environment
supports this feature. chatr(1) can be used to change this setting, including restoration of the
default setting, after the output file has been created.
-q
-q
-Q
-r
-s
The -q option causes the output file from the linker to be marked as demand-loadable.
For details and system defaults, refer to the description of ld in the HP-UX Reference Manual or the
ld(1) manpage for more information.
-Q
The -Q option causes the program file from the linker to be marked as not demand-loadable.
For details and system defaults, refer to the description of ld in the HP-UX Reference Manual or the
ld(1) manpage for more information.
-r
Use the -r option to retain relocation information in the output file for subsequent relinking.
-s
Using the -s option causes the executable program file created by the linker to be stripped of
symbol table information. Specifying this option prevents using a symbolic debugger on the resulting
program. For details and system defaults, refer to the description of ld in the HP-UX ReferenceManual or the ld(1) manpage for more information.
-usymbol
-usymbol
Enter symbol as an undefined symbol in ld’s symbol table. The resulting unresolved reference is
useful for linking a program solely from object files in a library. More than one symbol can be
specified, but each must be preceded by -u.
See ld(1) manpage for more information.
Linker Options51
+ild
+ild
The +ild option specifies incremental linking. If the output file does not exist, or if it was created
without the +ild option, the linker performs an initial incremental link. The output file produced
is suitable for subsequent incremental links. The incremental link option is valid for both executable
and shared library links. It is not valid for relocatable links, options or tools that strip the output
module, and certain optimization options.
When sum reduction optimization is enabled, the compiler may evaluate intermediate partial sums
of float or double precision terms using (wider) extended precision, which reduces variation in the
result caused by different optimization strategies and generally produces a more accurate result.
See ld(1) manpage for more information.
+ildrelink
+ildrelink
The +ildrelink option performs an initial incremental link, regardless of the output load module.
In certain situations during incremental linking (for example, internal padding space is exhausted),
the incremental linker is forced to perform an initial incremental link. The +ildrelink option
allows you to avoid such unexpected initial incremental links by periodically rebuilding the output
file.
See ld(1) manpage for more information.
Options for Naming the Output File
These options allow you to name the compilation output file something other than the default name.
-o
-o outfile
The outfile parameter is the name of the file containing the output of the compilation. This option
causes the output of the compilation to be placed in outfile.
Without this option the default name is a.out. When compiling a single source file with the -c
option, you can use the -o option to specify the name and location of the object file.
-.suffix
-.suffix
The suffix parameter represents the character or characters to be used as the output file name
suffix. suffix cannot be the same as the original source file name suffix. Using this option causes
the compiler to direct output from the -E option into a file with the corresponding .suffix instead
of into a corresponding .c file.
Example:
aCC -E -.i prog.C
This command preprocesses the code in prog.C and puts the resulting code in the file prog.i.
Native Language Support Option
The following is an option to enable native language support:
-Y
-Y
The -Y option enables Native Language Support (NLS) of 8-bit, 16-bit and 4-byte EUC characters
in comments, string literals, and character constants.
52Command-Line Options
The language value (refer to environ(5) for the LANG environment variable) is used to initialize
the correct tables for interpreting comments, string literals, and character constants. The language
value is also used to build the path name to the proper message catalog.
For more information and description of the NLS model, refer to hpnls, lang, and environ in
HP-UX Reference Manual.
Handling Null Pointers Options
The following options allow dereferencing of null pointers.
-z
-z
The -z option disallows dereferencing of null pointers at run time.
Fatal errors result if null pointers are dereferenced. If you attempt to dereference a null pointer, a
SIGSEGV error occurs at run time.
Example:
aCC -z file.C
The above command compiles file.C and generates code to disallow dereferencing of null
pointers.
For more information, see signal(2) and signal(5) manpages.
-Z
-Z
The -Z option allows dereferencing of null pointers at run time. This is the default. The value of a
dereferenced null pointer is zero.
Code Optimizing Options
Optimization options can be used to improve the execution speed of programs compiled with the
HP compiler.
To use optimization, first specify the appropriate basic optimization level (+O1, +O2, +O3, or +O4)
on the command line followed by one or more finer or more precise options when necessary.
For more information and examples, refer to Chapter 7: “Optimizing HP aC++ Programs” (page 156).
This section discusses the following topics:
•“Basic Optimization Level Options” (page 53)
•“Additional Optimization Options for Finer Control” (page 55)
•“Advanced +Ooptimization Options” (page 57)
•“Profile-Based Optimization Options” (page 64)
•“Displaying Optimization Information” (page 65)
Basic Optimization Level Options
The following options allow you to specify the basic level of optimization.
Compiling files at optimization level 2 ("-O" or "+O2") and above increases the amount of virtual
memory needed by the compiler. In cases where very large functions or files are compiled at +O2,
or in cases where aggressive (+O3 and above) optimization is used, ensure that the maxdsiz
kernel tunable is set appropriately on the machine where compilation takes place.
HP recommends a setting of 0x100000000, or 4 GB (the default for this parameter is
0x100000000, or 4 GB) for maxdsiz_64bit in such cases. Updating the maxdsiz_64bit
Handling Null Pointers Options53
-O
+O0
tunable will ensure that the compiler does not run out of virtual memory when compiling large files
or functions.
In addition, maxssiz_64bit should be set to 128 MB for very large or complex input files.
(Normally a maxssiz_64bit setting of 64 MB will be sufficient.)
See the kctune man page for more information on how to change kernel tunable parameters.
-O
The -O option invokes the optimizer to perform level 2 optimization. This option is equivalent to
+O2 option.
Example:
This command compiles prog.C and optimizes at level 2:
aCC -O prog.C
+O0
Use +O0 for fastest compile time or with simple programs. No optimizations are performed.
Example:
This command compiles prog.C and optimizes at level 0:
+O1
+O2
aCC +O0 prog.C
+O1
The +O1 option performs level 1 optimization only. This includes branch optimization, dead code
elimination, faster register allocation, instruction scheduling, peephole optimization, and generation
of data prefetch instructions for the benefit of direct (but not indirect) memory accesses. This is the
default optimization level.
Example:
This command compiles prog.C and optimizes at level 1:
aCC +O1 prog.C
+O2
The +O2 option performs level 2 optimization. This includes level 1 optimizations plus optimizations
performed over entire functions in a single file.
NOTE:Compiling with this optimization setting may require additional memory resources. Refer
to the memory resource discussion above.
Example:
This command compiles prog.C and optimizes at level 2:
aCC +O2 prog.C
+O3
+O3
The +O3 option performs level 3 optimization. This includes level 2 optimizations plus full
optimization across all subprograms within a single file.
54Command-Line Options
+O4
NOTE:Compiling with this optimization setting may require additional memory resources. Refer
to the memory resource discussion above.
Example:
This command compiles prog.C and optimizes at level 3:
aCC +O3 prog.C
+O4
The +O4 option performs level 4 optimization. This includes level 3 optimizations plus full
optimizations across the entire application program. Also, the defaults that depend on optimization
will be the defaults for +O3.
When you link a program, the compiler brings all modules that were compiled at optimization
level 4 into virtual memory at the same time. Depending on the size and number of the modules,
compiling at +O4 can consume a large amount of virtual memory. If you are linking a large program
that was compiled with the +O4 option, you may notice a system slow down. In the worst case,
you may see an error indicating that you have run out of memory.
NOTE:Compiling with this optimization setting may require additional memory resources. Refer
to the memory resource discussion above.
Example:
This command compiles prog.C and optimizes at level 4:
aCC +O4 prog.C
If you run out of memory when compiling at +O4 optimization, there are several things you can
do:
•Compile at +O4 only those modules that need to be compiled at optimization level 4, and
compile the remaining modules at a lower level.
•If you still run out of memory, increase the per-process data size limit. Run the System
Administrator Manager (SAM) to increase the maxdsiz_64bit process parameter to more
than 4GB. This procedure provides the process with additional data space.
•If increasing the per-process data size limit does not solve the problem, increase the system
swap space.
Refer to the System Administration Tasks manual for more information.
Object Files Generated at Optimization Level 4
Object files generated by the compiler with +O4 or -ipo, called intermediate object files, are
intended to be temporary files. These object files contain an intermediate representation of the user
code in a format that is designed for advanced optimizations. The size of these intermediate object
files can typically be 3 to 10 times as large as normal object files. Hewlett-Packard reserves the
right to change the format of these files without prior notice. There is no guarantee that intermediate
object files will be compatible from one revision of the compiler to the next. Use of intermediate
files must be limited to the compiler that created them. For the same reason, intermediate object
files should not be included into archived libraries that might be used by different versions of the
compiler. The compiler will issue an error message and terminate when an incompatible intermediate
file is generated.
Additional Optimization Options for Finer Control
Following are the additional optimizations options for finer control:
Code Optimizing Options55
-ipo
The -ipo option enables interprocedural optimizations across files. The object file produced using
this option contains intermediate code (IELF file). At link time,ld automatically invokes the
interprocedural optimizer (u2comp), if any of the input object files is an IELF file.
For optimization levels +O0 and +O1, this option is silently ignored.
The-ipo option will get implicitly invoked with the +O4 and +Ofaster options to match current
behavior (+O4 ==> +O3 -ipo).
For -ipo compilations, the back end is parallelized, and the level of parallelism can be controlled
with the environment variable PARALLEL, since the standard HP-UX make utility is used for the
parallelization.
Object Files Generated with -ipo
Object files generated by the compiler with +O4 or -ipo, called intermediate object files, are
intended to be temporary files. These object files contain an intermediate representation of the user
code in a format that is designed for advanced optimizations. The size of these intermediate object
files can typically be 3 to 10 times as large as normal object files. Hewlett-Packard reserves the
right to change the format of these files without prior notice. There is no guarantee that intermediate
object files will be compatible from one revision of the compiler to the next. Use of intermediate
files must be limited to the compiler that created them. For the same reason, intermediate object
files should not be included into archived libraries that might be used by different versions of the
compiler. The compiler will issue an error message and terminate when an incompatible intermediate
file is generated.
+[no]nrv
+[no]nrv
-nrv_optimization,[off|on]
The +[no]nrv option enables [disables] the named return value (NRV) optimization. By default
it is disabled.
The NRV optimization eliminates a copy-constructor call by allocating a local object of a function
directly in the caller’s context if that object is always returned by the function.
Example:
struct A{
A(A const&); //copy-constructor
};
A f(A constA x) {
A a(x);
return a; // Will not call the copy constructor if the
} // optimization is enabled.
This optimization will not be performed if the copy-constructor was not declared by the programmer.
Note that although this optimization is allowed by the ISO/ANSI C++ standard, it may have
noticeable side effects.
Example:
aCC -Wc,-nrv_optimization,on app.C
+O[no]failsafe
+O[no]failsafe
The +O[no]failsafe option enables [disables] failsafe optimization. When a compilation fails
at the current optimization level +Ofailsafe will automatically restart the compilation at +O2
(for specific high level optimizer errors +O3/+O4), O1, or +O0.
The default is +Ofailsafe.
56Command-Line Options
+O[no]aggressive
+O[no]aggressive
The +Oaggressive option enables aggressive optimizations. The +Onoaggressive option
disables aggressive optimizations.
By default, aggressive optimizations are turned off. The +Oaggressive option is approximately
equivalent to +Osignedpointers +Onoinitcheck +Ofltacc=relaxed.
NOTE:This option is deprecated and may not be supported in future releases. Instead you can
use +Ofastoption.
+O[no]limit
+O[no]limit
The +Olimit option enables optimizations that significantly increase compile time or that consume
a lot of memory.
The +Onolimit option suppresses optimizations regardless of their effect on compile time or
memory consumption.
Use +Onolimit at all optimization levels.
Usage:
+O[no]limit=level
The defined values of level are:
defaultBased on tuning heuristics, the optimizer will spend a reasonable amount of time
minFor large procedures, the optimizer will avoid non-linear time optimizations. This
processing large procedures. This is the default option.
option is a synonym for +Olimit.
noneThe optimizer will fully optimize large procedures, possibly resulting in significantly
increased compile time. This option is a synonym for +Onolimit.
Example:
To remove optimization time restrictions at O2, O3, or O4 optimization levels, use +Onolimit as
follows:
aCC <opt level> +Onolimit sourcefile.C
+O[no]ptrs_to_globals[=list]
+O[no]ptrs_to_globals[=list]
The +O[no]ptrs_to_globals option tells the optimizer whether global variables are accessed
[are not accessed] through pointers. If +Onoptrs_to_globals is specified, it is assumed that
statically-allocated data (including file-scoped globals, file-scoped statics, and function-scoped
statics) will not be read or written through pointers. The default is +Onoptrs_to_globals.
+O[no]size
+O[no]size
While most optimizations reduce code size, the +Osize option suppresses those few optimizations
that significantly increase code size. The +Onosize option enables code-expanding optimizations.
Use +Osize at all optimization levels. The default is +Onosize.
Advanced +Ooptimization Options
Advanced optimization options provide additional control for special situations.
Code Optimizing Options57
+O[no]cross_region_addressing
+O[no]cross_region_addressing
The +O[no]cross_region_addressing option enables [disables] the use of cross-region
addressing. Cross-region addressing is required if a pointer, such as an array base, points to a
different region than the data being addressed due to an offset that results in a cross-over into
another region. Standard conforming applications do not require the use of cross-region addressing.
The default is +Onocross_region_addressing.
NOTE:Using this option may result in reduced runtime performance.
+O[no]datalayout
+O[no]datalayout
The +O[no]datalayout option enables [disables] profile-driven layout of global and static data
items to improve cache memory utilization. This option is currently enabled if +Oprofile=use
(dynamic profile feedback) is specified.
The default, in the absence of +Oprofile=use, is +Onodatalayout.
+O[no]dataprefetch
+O[no]dataprefetch
When +Odataprefetch is enabled, the optimizer inserts instructions within innermost loops to
explicitly prefetch data from memory into the data cache. Data prefetch instructions are inserted
only for data structures referenced within innermost loops using simple loop varying addresses
(that is, in a simple arithmetic progression).
Use this option for applications that have high data cache miss overhead.
+Odataprefetch is equivalent to +Odataprefetch=indirect. +Onodataprefetch is
equivalent to +Odataprefetch=none.
Usage:
+Odataprefetch=kind
The defined values for kind are:
directEnable generation of data prefetch instructions for the benefit of direct memory
indirectEnables the generation of data prefetch instructions for the benefit of both direct and
noneDisables the generation of data prefetch instructions. This is the default at optimization
+O[no]fltacc
+O[no]fltacc=level
The +O[no]fltacc option disables [enables] floating-point optimizations that can result in
numerical differences. Any option other than +Ofltacc=strict also generates Fused Multiply-Add
(FMA) instructions. FMA instructions can improve performance of floating-point applications.
If you specify neither +Ofltacc nor +Onofltacc, less optimization is performed than for
+Onofltacc. If you specify neither option, the optimizer generates FMA instructions but does not
perform any expression-reordering optimizations.
Specifying +Ofltacc insures the same result as in unoptimized code (+O0).
accesses, but not indirect memory accesses. This is the default at optimization level
+O1.
indirect memory accesses. This is the default at optimization levels +O2 and above.
It is treated the same as direct at optimization level +O1.
level +O0.
Usage:
58Command-Line Options
+Ofltacc=level
The defined values for level are:
defaultAllows contractions, such as fused multiply- add (FMA), but disallows any other
floating-point optimization that can result in numerical differences.
limitedLike default, but also allows floating-point optimizations which may affect the
generation and propagation of infinities, NaNs, and the sign of zero.
relaxedIn addition to the optimizations allowed by limited, permits optimizations, such as
reordering of expressions, even if parenthesized, that may affect rounding error. This
is the same as +Onofltacc.
strictDisallows any floating-point optimization that can result in numerical differences. This
is the same as +Ofltacc.
All options except +Ofltacc=strict option allow the compiler to make transformations which
are algebraically correct, but which may slightly affect the result of computations due to the inherent
imperfection of computer floating-point arithmetic. For many programs, the results obtained with
these options are adequately similar to those obtained without the optimization.
For applications in which round-off error has been carefully studied, and the order of computation
carefully crafted to control error, these options may be unsatisfactory. To insure the same result as
in unoptimized code, use +Ofltacc.
Example:
All the options, except +Ofltacc=strict, allow the compiler to replace a division by a
multiplication using the reciprocal. For example, the following code:
for (int j=1;j<5;j++)
a[j] = b[j] / x;
is transformed as follows (note that x is invariant in the loop):
Since multiplication is considerably faster than division, the optimized program runs faster.
+Ofrequently_called
+Ofrequently_called=function1[,function2...]
The named functions are assumed to be frequently called. This option overrides any information
in a profile database.
+Ofrequently_called:filename
The file indicated by filename contains a list of functions, separated by spaces or newlines.
These functions are assumed to be frequently called. This option overrides any information in a
profile database.
+O[no]initcheck
+O[no]initcheck
The initialization checking feature of the optimizer can be on or off:
When on (+Oinitcheck), the optimizer issues warning messages when it discovers uninitialized
variables.
When off (+Onoinitcheck), the optimizer does not issue warning messages.
Use +Oinitcheck at optimization level 2 or above. If this option is used together with
+check=uninit, uninitialized variables will remain uninitialized so that an error will be reported
at runtime and trigger a program abort if the variables are accessed.
Code Optimizing Options59
+O[no]inline
+O[no]inline
The +Oinline option indicates that any function can be inlined by the optimizer. +Onoinline
disables inlining of functions by the optimizer. This option does not affect functions inlined at the
source code level.
Use +O[no]inline at optimization levels 2, 3 and 4.
The default is +Oinline at optimization levels 3 and 4.
Usage:
+O[no]inline=function1{,function2...]
Enables [disables] optimizer inlining for the named functions.
+O[no]inline:filename
The file indicated by filename should contain a list of function names, separated by commas or
newlines. Optimization is enabled [disabled] for the named functions.
+Olit
+Olit=kind
The +Olit option places the data items that do not require load-time or runtime initialization in a
read-only data section. +Olit=all is the default for both HP aC++ and HP C. This represents a
change from earlier versions of the HP C compiler, which defaulted to +Olit=const. Note that
if you attempt to modify the constant or literal, a runtime signal 11 will be generated.
The defined values for kind are:
allAll string literals and all const-qualified variables that do not require load-time or runtime
initialization will be placed in a read-only data section. +Olit=all replaces the
deprecated +ESlit option.
constAll string literals appearing in a context where const char * is legal, and all
const-qualified variables that do not require load-time or runtime initialization will be
placed in a read-only data section. +Olit=const is mapped to +Olit=all with a
warning, except in C mode. +Olit=const replaces the deprecated +ESconstlit
option in C.
noneNo constants are placed in a read-only data section. +Olit=none replaces the
deprecated +ESnolit option.
+Ointeger_overflow
+Ointeger_overflow=kind
To provide the best runtime performance, the compiler makes assumptions that runtime integer
arithmetic expressions that arise in certain contexts do not overflow (produce values that are too
high or too low to represent) both expressions that are present in user code and expressions that
the compiler constructs itself. Note that if an integer arithmetic overflow assumption is violated,
runtime behavior is undefined.
+Ointeger_overflow=moderate is the default for all optimization levels. This was changed
to enable a wider class of applications to be compiled with optimization and run correctly.
The defined values of kind are:
conservativeDirects the compiler to make fewer assumptions that integer arithmetic
moderateAllows the compiler to make a broad set of assumptions so that the integer
expressions do not overflow.
arithmetic expressions do not overflow, except that linear function test
replacement (LFTR) optimization is not performed.
60Command-Line Options
+Olevel
+Olevel=name1[,name2,...,nameN]
The +Olevel option lowers optimization to the specified level for one or more named functions.
level can be 0, 1, 2, 3, or 4.
The name parameters are names of functions in the module being compiled. Use this option when
one or more functions do not optimize well or properly. This option must be used with a basic
+Olevel or -O option. Note that currently only the C++ mangled name of the function is allowed
for name.
This option works like the OPT_LEVEL pragma. The option overrides the pragma for the specified
functions. As with the pragma, you can only lower the level of optimization; you cannot raise it
above the level specified by a basic +Olevel or -O option. To avoid confusion, it is best to use
either this option or the OPT_LEVEL pragma rather than both.
You can use this option at optimization levels 1, 2, 3, and 4. The default is to optimize all functions
at the level specified by the basic +Olevel or -O option.
Examples:
•The following command optimizes all functions at level 3, except for the functions myfunc1
and myfunc2, which it optimizes at level 1.
aCC +O3 +O1=myfunc1,myfunc2 funcs.c main.c
•The following command optimizes all functions at level 2, except for the functions myfunc1
and myfunc2, which it optimizes at level 0.
aCC -O +O0=myfunc1,myfunc2 funcs.c main.c
+O[no]loop_transform
+O[no]loop_transform
This option transforms [does not transform] eligible loops for improved cache and other performance.
This option can be used at optimization levels 2, 3 and 4.
The default is +Oloop_transform.
+O[no]loop_unroll
+O[no]loop_unroll [=unroll_factor]
The +O[no]loop_unroll option enables [disables] loop unrolling. This optimization can occur
at optimization levels 2, 3, and 4. The default is +Oloop_unroll. The default is 4, that is, four
copies of the loop body. The unroll_factor controls code expansion. Note that
+Onoloop_unroll has no effect on loop unroll-and-jam.
+O[no]openmp
+O[no]openmp
The +Oopenmp option causes the OpenMP directives to be honored. This option is effective at any
optimization level. Non OpenMP parallelization directives are ignored with warnings. +Onoopenmp
requests that OpenMP directives be silently ignored. If neither +Oopenmp nor +Onoopenmp is
specified, OpenMP directives will be ignored with warnings.
The OpenMP specification is available at http://www.openmp.org/specs. OpenMP programs
require the libomp and libcps runtime support libraries to be present on both the compilation
and runtime systems. The compiler driver automatically includes them when linking.
If you use +Oopenmp in an application, you must use -mt with any files that are not compiled
with +Oopenmp. For additional information and restrictions, See “-mt” (page 66).
Code Optimizing Options61
It is recommended that you use the -N option when linking OpenMP programs to avoid exhausting
memory when running with large numbers of threads.
NOTE:HP aC++ version A.06.00 does not support C++ constructs in OpenMP. Use the
+legacy_v5 option to use this option.
+opts
+opts filename
The file indicated by filename contains a list of options that are processed as if they had been
specified on the command line at the point of the +opts option. The options must be delimited by
a blank character. You can add comments to the option file by using a "#" character in the first
column of a line. The "#" causes the entire line to be ignored by the compiler.
Example:
$ aCC +opts GNUOptions foo.c
Where GNUOptions contains:
#This file contains the set of options for programs needing GNU support -Ag++ -Wc,--fshort-enums
+O[no]parminit
+O[no]parminit
The +O[no]parminit option enables [disables] automatic initialization to non-NaT of unspecified
function parameters at call sites. This is useful in preventing NaT values in parameter registers. The
default is +Onoparminit.
+O[no]parmsoverlap
+O[no]parmsoverlap
The +Onoparmsoverlap option optimizes with the assumption that on entry to a function each
of that function’s pointer-typed formals points to memory that is accessed only through that formal
or through copies of that formal made within the function. For example, that memory must not be
accessed through a different formal, and that formal must not point to a global that is accessed by
name within the function or any of its calls.
Use +Onoparmsoverlap if C/C++ programs have been literally translated from FORTRAN
programs.
The default is +Oparmsoverlap.
+O[no]procelim
+O[no]procelim
The +O[no]procelim option enables [disables] the elimination of dead procedure code and
sometimes the unreferenced data.
Use this option when linking an executable file, to remove functions not referenced by the
application. You can also use this option when building a shared library to remove functions not
exported and not referenced from within the shared library. This may be especially useful when
functions have been inlined.
NOTE:Any function having symbolic debug information associated with it is not removed.
The default is +Onoprocelim at optimization levels 0 and 1; at levels 2, 3 and 4, the default is
+Oprocelim.
+O[no]promote_indirect_calls
+O[no]promote_indirect_calls
62Command-Line Options
The +O[no]promote_indirect_calls option uses profile data from profile-based optimization
and other information to determine the most likely target of indirect calls and promotes them to
direct calls. Indirect calls occur with pointers to functions and virtual calls.
In all cases the optimized code tests to make sure the direct call is being taken and if not, executes
the indirect call. If +Oinline is in effect, the optimizer may also inline the promoted calls.
+Opromote_indirect_calls is only effective with profile-based optimization.
NOTE:The optimizer tries to determine the most likely target of indirect calls. If the profile data
is incomplete or ambiguous, the optimizer may not select the best target. If this happens, your
code’s performance may decrease.
This option can be used at optimization levels 3 and 4. At +O3, it is only effective if indirect calls
from functions within a file are mostly to target functions within the same file. This is because +O3
optimizes only within a file, whereas +O4 optimizes across files.
The default is +Opromote_indirect_calls at optimization level 3 and above.
+Onopromote_indirect_calls will be the default at optimization level 2 and below.
+Orarely_called
+Orarely_called=function1[,function2...]
The +Orarely_called option overrides any information in a profile database.
The named functions are assumed to be rarely called
+Orarely_called:filename
The file indicated by filename contains a list of functions, separated by spaces or newlines. These
functions are assumed to be rarely called. This option overrides any information in a profile
database.
+O[no]signedpointers
+O[no]signedpointers
NOTE:This option is deprecated and may not be supported in future releases.
The +Osignedpointers option treats pointers in Boolean comparisons (for example, <, <=, >,
>=) as signed quantities. Applications that allocate shared memory and that compare a pointer
to shared memory with a pointer to private memory may run incorrectly if this optimization is
enabled.
The default is +Onosignedpointers.
NOTE:This option is supported in C-mode only. A warning is displayed in C++ when this option
is used.
+Oshortdata
+Oshortdata[=size]
All objects of [size] bytes or smaller are placed in the short data area, and references to such
data assume it resides in the short data area. Valid values of size are a decimal number between
8 and 4,194,304 (4MB).
If no size is specified, all data is placed in the short data area. The default is +Oshortdata=8.
NOTE:Using a value that is too big or without the optional size, possibly through +Ofast, may
give various linker fix up errors, if there is more than 4Mb of short data.
Code Optimizing Options63
+O[no]store_ordering
+O[no]store_ordering
The +O[no]store_ordering option preserves [does not preserve] the original program order
for stores to memory that is visible to multiple threads. This does not imply strong ordering. The
default is +Onostore_ordering.
+Otype_safety
+Otype_safety=kind
The +Otype_safety option controls type-based aliasing assumptions.
The defined values for kind are:
offThe default. Specifies that aliasing can occur freely across types.
limitedCode follows ANSI aliasing rules. Unnamed objects should be treated as if they had
ansiCode follows ANSI aliasing rules. Unnamed objects should be treated the same as
strongCode follows ANSI aliasing rules, except that accesses through lvalues of a
The default is +Otype_safety=off.
an unknown type.
named objects.
character type are not permitted to touch objects of other types and field addresses
are not to be taken.
+Ounroll_factor
+Ounroll_factor=n
The +Ounroll_factor option applies the unroll factor to all loops in the current translation unit.
You can apply an unroll factor which you think is best for the given loop or apply no unrolling
factor to the loop. If this option is not specified, the compiler uses its own heuristics to determine
the best unroll factor for the inner loop.
A user specified unroll factor will override the default unroll factor applied by the compiler.
Specifying n=1 will prevent the compiler from unrolling the loop.
Specifying n=0 allows the compiler to use its own heuristics to apply the unroll factor.
NOTE:This option will be ignored if it is placed in a loop other than the innermost loop.
Profile-Based Optimization Options
Profile-based optimization is a set of performance-improving code transformations based on the
runtime characteristics of your application.
+Oprofile
+Oprofile=[use|collect]
The +Oprofile option instructs the compiler to instrument the object code for collecting runtime
profile data. The profiling information can then be used by the linker to perform profile-based
optimization. When an application finishes execution, it will write profile data to the fileflow.data
or to the file/path in the environment variable FLOW_DATA (if set).
+Oprofile=use[:filename] causes the compiler to look for a profile database file. If a
filename is not specified, the compiler will look for a file named "flow.data" or the file/path
specified in the FLOW_DATA environment variable. If a filename is specified, it overrides the
FLOW_DATA environment variable.
After compiling and linking with +Oprofile=collect, run the resultant program using
representative input data to collect execution profile data. Profile data is stored in flow.data by
64Command-Line Options
default. The name is generated as flow.<suffix> if there is already a flow.datafile present
in the current directory. Finally, recompile with the +Oprofile=use option (passing it the
appropriate filename if necessary) to perform profile-based optimization.
Example:
aCC +Oprofile=collect -O -o prog.pbo prog.C
The above command compiles prog.C with optimization, prepares the object code for data
collection, and creates the executable file prog.pbo. Running prog.pbo collects runtime
information in the file flow.data in preparation for optimization with +Oprofile=use.
+Oprofile=collect [:<qualifiers>]
<qualifiers> are a comma-separated list of profile collection qualifiers.
Supported profile collection qualifiers:
arcEnables collection of arc counts.
dcacheEnables collection of data cache misses.
strideEnables collection of stride data.
loopiterEnables collection of loop iteration counts..
allEnables collection of all types of profile data. This is equivalent to
+Oprofile=collect:arc,dcache,stride,loopiter. This is the default.
This option merely enables the application for collection of the various forms of profiling data.
The environment variable PBO_DATA_TYPE controls the type of data collected at runtime. It may
be set to one of the following values, which must be consistent with the +Oprofile=collect
qualifiers used to create the application:
arc-strideCollects stride and/or arc counts. This is the default if PBO_DATA_TYPE is
not set.
dcacheCollects data cache miss metrics.
NOTE:Data cache miss metrics cannot be collected during the same run of an application as
stride and/or arc data.
Information Embedding Options
The +annotate option annotates the compiled binary with extra information.
-annotate=structs
The+annotate option annotates the compiled binary with accesses to C/C++ struct fields for
use by other external tools such as Caliper. By default, no annotations are added.
Displaying Optimization Information
The +O[no]info option displays informational messages about the optimization process.
+O[no]info
+O[no]info
The +O[no]info option displays messages about the optimization process. This option may be
helpful in understanding what optimizations are occurring. You can use the option at levels 0-4.
The default is +Onoinfo at levels 0-4.
Parallel Processing Options
HP aC++ provides the following optimization options for parallel code.
Parallel Processing Options65
-mt
The -mt option enables multi-threading capability without the need to set any other flags, such as
-l and -D. HP aC++ examines your environment and automatically selects and sets the appropriate
flags. “Performance Options” (page 167).
There are three possible sets of flags depending on your operating system and the libstd you
use. Table 5 lists the option matrix for -mt.
Table 5 Option Matrix for -mt
FlagsLibraries
-D_REENTRANTold-lib
libstd 1.2.1
(-AP)&
librwtool 7.0.x
(-AA)
libstd 2.2.1
-DRW_MULTI_THREAD
-DRWSTD_MULTI_THREAD
-D_THREAD_SAFE
-D_POSIX_C_SOURCE=199506L
-D_HPUX_SOURCE *
-lpthread
-D_REENTRANTnew-lib
-D_RW_MULTI_THREAD
-D_RWSTD_MULTI_THREAD
-D_POSIX_C_SOURCE=199506L
-D_HPUX_SOURCE *
-lpthread
-D_REENTRANTC mode
-Ae/-Aa
-D_POSIX_C_SOURCE=199506L
-lpthread
* required if -D_POSIX_C_SOURCE is used.
NOTE:For C++ and C -Ae -D_HPUX_SOURCE is set to be compatible with the default when
-mt is not used. For C mode options -AC89, -AC99, and -Aa, -D_HPUX_SOURCE is also set. Ifyou do not want to use-D_HPUX_SOURCE, you can undefine it by using -U. Example:
-U_HPUX_SOURCE
The following macros are used to compile multi-thread source code:
•_REENTRANT
Required by system header files that provide reentrant functions (suffixed by _r).
•RW_MULTI_THREAD / _RW_MULTI_THREAD
Required by Rogue Wave toolsh++ header files and libraries. RW_MULTI_THREAD is used
by toolsh++ 7.0.x. _RW_MULTI_THREAD is used by toolsh++ 8.x (not available yet).
•RWSTD_MULTI_THREAD / _RWSTD_MULTI_THREAD
Required by Rogue Wave standard library header files and libraries. RWSTD_MULTI_THREAD
is used by libstd 1.2.1. _RWSTD_MULTI_THREAD is used by libstd 2.2.1 when compiling
with -AA.
66Command-Line Options
•_POSIX_C_SOURCE=199506L
Required by pthread.
•libpthread.*
Kernel thread library used on 11.x systems
See “Using Threads” (page 163) for more information.
NOTE:Make sure that -mt is used consistently at compile and link times. When you link with
-mt, everything must be compiled with -mt, even if you do not think your file will be used in a
threaded application. When you incorrectly mix and match with -mt, you get a runtime abort with
the following message:
aCC runtime: Use of "-mt" must be consistent during both compilation and linking.
To find the library or object that is missing -mt, use /usr/ccs/bin/footprints and look for
the following:
-mt [(off) 1] -mt [on 1] (Or not present)
The number 1 above is the count of objects with that -mt setting. Not present implies the source
was not compiled with a recent compiler that contains this information.
+O[no]autopar
+O[no]autopar
The +Oautopar option enables automatic parallelization of loops that are deemed safe and
profitable by the loop transformer.
Usage:
This optimization allows applications to exploit otherwise idle resources on multicore or
multiprocessor systems by automatically transforming serial loops into multithreaded parallel code.
When the +Oautopar option is used at optimization levels +O3 and above, the compiler
automatically parallelizes those loops that are deemed safe and profitable by the loop transformer.
Automatic parallelization can be combined with manual parallelization through the use of OpenMP
directives and the +Oopenmp option. When both +Oopenmp and +Oautopar options are specified,
then any existing OpenMP directives take precedence, and the compiler will only consider
auto-parallelizing other loops that are not controlled by those directives.
Programs compiled with the +Oautopar option require the libcps, libomp, and libpthreads runtime
support libraries to be present at both compilation and runtime. When linking with the HP-UX
B.11.61 linker, compiling with the +Oautoparoption causes them to be automatically included.
Older linkers require those libraries to be specified explicitly or by compiling with +Oopenmp.
The +Oautopar option is supported when compiling C, C++, or Fortran files. Specifying
+Oautopar implies the -mt option.
The default is +Onoautopar, which disables automatic parallelization of loops.
+tls=[static|dynamic]
+tls=[static|dynamic]
The +tls option specifies whether references to thread local data items are to be performed
according to the mode.
Usage:
+tls=mode
The defined values of mode are:
staticThis is a more efficient mode in which only thread local data in the program startup
set can be accessed.
Parallel Processing Options67
dynamicThis is a less efficient mode in which thread local data outside the program startup
set can be accessed as well. This is the default.
Translation units compiled with different settings of this option may be freely mixed, even within
the same load module.
+wlock
+wlock
The +wlock option enables compile-time diagnostic messages for potential errors in using
lock/unlock calls in programs that use pthread-library-based lock/unlock functions. Warnings are
emitted for acquiring an already acquired lock, releasing an already released lock, and
unconditionally releasing a lock that has been conditionally acquired.
This diagnostic checking is based on cross-module analysis performed by the compiler. Therefore,
the +wlockoption implicitly enables a limited form of cross-module analysis, even if -ipo or+O4
options are not specified. This can lead to a significant increase in the compile time compared to
a build without the +wlock option. Using this option could result in the compiler invoking
optimizations other than those that are part of the user-specified optimization level. If +wlock is
used in addition to -ipo or +O4, the generated code is not affected, and the compile time does
not increase much.
Performance Options
The HP compiler provides a variety of options to help improve build and runtime performance.
These options are:
-fast
+Ofast
-fast
The -fast option selects a combination of optimization options for optimum execution speed and
reasonable build times. This option is equivalent to +Ofast. Currently chosen options are:
•+O2
•+Ofltacc=relaxed
•+Onolimit
•+DSnative
•+FPD
You can override any of the options in -fast by specifying a subsequent option after it.
Use this option when porting C++ and C applications compiled on other UNIX operating systems
to HP-UX.
NOTE:Do not use this option for programs that depend on IEEE standard floating-point
denormalized numbers. Otherwise, different numerical results may occur.
+Ofast
The +Ofast option selects a combination of optimization options for optimum execution speed
for reasonable build times. Currently chosen options are:
•+O2
•+Ofltacc=relaxed
•+Onolimit
•+DSnative
68Command-Line Options
•+FPD
•-Wl,+pi,1M
•-Wl,+pd,1M
•-Wl,+mergeseg
This option is a synonym for -fast.
NOTE:Do not use this option for programs that depend on IEEE standard floating point
denormalized numbers. Otherwise, different numerical results may occur. See +Ofltacc=relaxed.
+Ofaster
+Ofaster
The +Ofaster option is equivalent to +Ofast with an increased optimization level. The definition
of +Ofaster may change, or the option may be deprecated in future releases.
+O[no]tls_calls_change_tp
+O[no]tls_calls_change_tp
The +O[no]tls_calls_change_tp option specifies whether or not function calls can change the value
of the thread pointer(tp), resulting in less aggressive optimizations to TLS variables which are
accessed by name.
+[no]srcpos
+[no]srcpos
The +[no]srcpos option controls the generation of source position information for HP Caliper.
The default is +srcpos.
When +srcpos, is in effect, the compiler generates source position information. When +nosrcpos
is in effect, the compiler does not generate this information and the compiler instructs the linker to
discard any of this information found in the object files.
+DSmodel
+DSmodel
The +DSmodel option performs instruction scheduling for a particular implementation of the
Itanium®-based architecture. The default is blended.
model any of the values below.
blendedTune to run reasonably well on multiple implementations. As old implementation
itanium
itanium2
mckinley
become less important and new implementations are added, the behavior with
this value will change accordingly.
Tune for the Itanium® processor.
Tune for the Itanium2® processor.
See itanium2® .
montecito
poulson
nativeTune for the processor on which the compiler is running.
Tune for the Montecito® processor.
Tune for the Poulson® processor.
Performance Options69
Porting Options
Use the following options as necessary when porting your code from other operating environments
to HP-UX.
-fast
-fast
The -fast option selects a combination of optimization options for optimum execution speed and
reasonable build times. Currently chosen options are:
•+O2
•+Ofltacc=relaxed
•+Onolimit
•+DSnative
•+FPD
You can override any of the options in -fast by specifying a subsequent option after it. This
option is equivalent to +Ofast.
Use this option when porting C++ and C applications compiled on other UNIX operating systems
to HP-UX.
NOTE:Do not use this option for programs that depend on IEEE standard floating-point
denormalized numbers. Otherwise, different numerical results may occur.
+sb
+ub
+uc
+sb
The +sb option specifies unqualified char, short, int,long, and long long bitfields as
signed. The default is +sb.
NOTE:When both +sb and +uc are in effect, +uc will override this for char bit fields.
+ub
The +ub option specifies unqualified char, short, int, long, and long long bitfields as
unsigned. This option has no effect on signedness of enum bitfields or on signedness of non-bitfield
char. The default is +sb.
+uc
By default, all unqualified char data types are treated as signed char. Specifying +uc causes an
unqualified (plain) char data type to be treated as unsigned char. (Overloading and mangling
are unchanged.)
Use this option to help in porting applications from environments where an unqualified (plain)
char type is treated as unsigned char.
NOTE:Since all unqualified char types in the compilation unit will be affected by this option
(including those headers that define external and system interfaces), it is necessary to compile the
interfaces used in a single program uniformly.
70Command-Line Options
+w64bit
The +w64bit option enables warnings that help detection of potential problems in converting
32-bit applications to 64-bit. The option is equivalent to the +M2 option.
+wdriver
The +wdriver option enables warnings for PA-RISC options that would otherwise be ignored
silently on Integrity servers. With the addition of this option in version A.06.05, a number of
warnings for PA options that had been reported by previous compiler versions were changed to
be silently ignored by default. The intent is to give good PA-RISC to Integrity makefile compatibility
by default, but provide this option to help users clean up unnecessary or misleading use of legacy
options when desired.
+wendian
This option allows the user to identify areas in their source code that might have porting issues
when going between little-endian and big-endian.
+wendian will warn of a de-reference that could cause endian-dependent behavior:
This warning can be suppressed by adding an extra cast:
fread((char*)(void*)ai, sizeof(char), 1, stdin); // OK
Another +wendian warning captures cases where a cast when later dereferenced can cause
endian issues.
Porting Options71
Preprocessor Options
The following options are accepted by the preprocessor:
-C
-C
Using the -C option prevents the preprocessor from stripping comments. See the description of
cpp in the cpp(1) manpage for details.
-dM
-dM
When -dM is present, instead of normal preprocessor output the compiler lists the #define
directives it encounters as it preprocesses the file, thus providing a list of all macros that are in
effect at the start of the compilation. The -dM option requires that -P or -E also be specified.
A common use of this option is to determine the compiler's predefined macros. For example:
touch foo.c ; cc -E -dM foo.c
-Dname
-Dname[=def]
name is the symbol name that is defined for the preprocessor.
-E
def is the definition of the symbol name (name).
The -Dname option defines a symbol name (name) to the preprocessor, as if defined by the
preprocessing directive#define.
If no definition (def) is given, the name is defined as 1.
NOTE:__ia64 and __HP_aCC are defined automatically.
Example:
The following example defines the preprocessor symbol DEBUGFLAG and gives it the value 1.
aCC -DDEBUGFLAG file.C
The following program uses this symbol:
#include <iostream.h>
int main(){
int i, j;
#ifdef DEBUGFLAG
int call_count=0;
#endif
/* ... */
}
-E
Using the -E option runs only the preprocessor on the named C++ files and sends the result to
standard output (stdout).
An exception to this rule is when-E is used with +Make[d] option, the only output is the make
dependency information. Unlike the -P option, the output of -E contains #line entries indicating
the original file and line numbers.
Redirecting Output From This Option
Use the -.suffix option to redirect the output of this option.
72Command-Line Options
make[d]
+make[d]
The +make[d] option directs a list of the quote enclosed (" ") header files upon which your source
code depends to stdout. The list is in a format accepted by the make command.
If +maked is specified, the list is directed to a .d file. The .d file name prefix is the same as that
of the object file. The .d file is created in the same directory as the object file.
Usage:
Use +maked when you also specify the -E or the -P option. When used with the -E option, only
dependency information is generated.
Table 6 lists examples of the +make[d] option.
Table 6 Examples
+Make[d]
+Make[d]
The +Make[d] option directs a list of both the quote enclosed (" ") and angle bracket enclosed
(< >) header files upon which your source code depends to stdout. The list is in a format accepted
by the make command.
If +Maked is specified, the list is directed to a .d file. The .d file name prefix is the same as that
of the object file. The .d file is created in the same directory as the object file.
Usage:
Use +Maked when you also specify the -E or the -P option. When used with the -E option, only
dependency information is generated.
Table 7 Examples
.d file location.d file nameCommand line Specified
Using the -P option only preprocesses the files named on the command line without invoking
further phases. It leaves the result in corresponding files with the suffix .i.
For example, the following command preprocesses the file prog.C leaving the output in the file
prog.i. It does not compile the program.
aCC -P prog.C
Preprocessor Options73
-Uname
-Uname
name is the symbol name whose definition is removed from the preprocessor.
This option undefines any name that has initially been defined by the preprocessing stage of
compilation.
A name can be a definition set by the compiler. This is displayed when you specify the -v option.
A name can also be a definition that you have specified with the -D option on the command line.
The -D option has lower precedence than the -U option. If the same name is used in both, the -U
option and the -D option, the name is undefined regardless of the order of the options on the
command line.
Profiling Code Options
HP compilers provides the following options for profiling your code.
-G
-G
At compile time, the -G option produces code that counts the number of times each arc in the call
graph is traversed. At link-time, when you are building an executable (but not a shared library)
-G picks up profiled versions of certain system libraries and picks up the gprof support library.
Example:
aCC -G file.C
The above example compiles file.C and creates the executable file a.out instrumented for use
with gprof.
See gprof(1) manpage for more information.
-p
-p
At compile time, the -p option produces code that counts the number of times each routine is
called. At link-time, when you are building an executable (but not a shared library) -p picks up
profiled versions of certain system libraries and picks up the prof support library.
Example:
The following example compiles file.C and creates the executable file a.out instrumented for
use with prof.
aCC -p file.C
See the prof(1) manpage for more information.
+profilebucketsize
+profilebucketsize=[16|32]
This is a link-time option to support prof and gprof when building an executable, but not a
shared library. When prof or gprof startup code invokes sprofil, this option specifies the
size in bits of the counters used to record sampled values of the program counter.
The effect of this option can be overridden by setting the environment variable
LD_PROFILEBUCKET_SIZE when running the instrumented program. This environment variable
has no effect when building the instrumented program. Legal values are 16 (the default), and 32.
See gprof(1) and ld(1) manpages for more details.
74Command-Line Options
Runtime Checking Options
The +check options allow you to check your application for errors at runtime.
The +check=xxx options provide runtime checks to detect many common coding errors in the
user program. These options introduce additional instructions for runtime checks that can significantly
slow down the user program. By default, a failed check will result in the program aborting at the
end of execution at runtime. In most cases, an error message and a stack trace will be emitted to
stderr before program termination. The environment variable RTC_NO_ABORT can be set to
0, 1, or 2 to change the behavior of failed runtime checks:
•0 — A failed runtime check will abort the program immediately after the error message is
emitted.
•1 — The default setting, which will abort the program at the end of execution upon failure.
•2 — A failed runtime check will not enable the end of execution abort.
The +check options need to be specified at both compile time and link time, since they may
require additional libraries to be linked into the user program. If different +check options are
specified while compiling different source files, all the specified +check options are needed at
link time.
Multiple +check options are interpreted left to right. In case of conflicting options, the one on the
right will override an earlier +check option.
NOTE:The +check option is only supported on Integrity servers.
+check=all
The +check=all option enables all runtime checks provided by the compiler, except for
+check=truncate, +check=lock, and +check=thread, which must be explicitly specified
to enable them. It overrides any +check=xxx options that appear earlier on the command line.
The +check=all option is currently equivalent to the following options:
The -z option, which is part of +check=all, can be overridden by an explicit -Z option.
+check=none
The +check=none option turns off all runtime checking options. It disables any +check=xxxoptions
that appear earlier on the command line.
+check=bounds
The +check=bounds option enables checks for out-of-bounds references to array variables or to
buffers through pointer access. The check is performed for each reference to an array element or
pointer access. If a check fails, an error message is emitted and the program is aborted.
The +check=bounds option applies only to local and global array variables. It also applies to
references to array fields of structs. It does not apply to arrays allocated dynamically using malloc
or alloca.
You can specify one of the following +check=bounds suboptions:
•array - Enables check for out-of-bounds references to array variables.
•pointer - Enables check for out-of-bounds references to buffers through pointer access. The
buffer could be a heap object, global variable, or local variable. This suboption also checks
out-of-bounds access through common libc function calls such as strcpy, strcat, memset,
Runtime Checking Options75
and so on. The check can create significant run-time performance overhead. See
+check=uninit and +check=malloc for their interaction with this option.
•all - Enables out-of-bounds checks for both arrays and pointers. This is equal to
+check=bounds:array +check=bounds:pointer.
•none - Disables out-of-bounds checks.
+check=bounds (with no suboption) is equal to +check=bounds:array. This may change in
the future to also include +check=bounds:pointer.
When +check=all is specified, it enables +check=bounds:array only. To enable the pointer
out-of-bounds check, you must explicitly specify +check=bounds:pointer.
You can combine +check=bounds:[pointer | all] with all other +check options, except
for +check=globals (which would be ignored in this case).
Also see the +check=malloc and the +check=stack options for related runtime checks for
heap and stack objects.
Example:
This example uses +check=bounds:pointer to find a program bug:
$ cat rttest3.c 1 #include <stdio.h>
2 #include <memory.h>
3 #include <stdlib.h>
4 5 int a[10];
6 char b[10];
7 int *ip = &a[0]; // points to global array
8
9 int i;
10
11 void *foo(int n)
12 {
13 return malloc(n * sizeof(int));
14 }
15
16 int main(int argc, char **argv)
17 {
18 int j; // uninitialized variable
19
20 int *lp = (int*)foo(10); // points to heap object
21
22 // out of bound if "a.out 10"
23 if (argc > 1) {
24 i = atoi(argv[1]);
25 }
26
27 memset(b, 'a', i);
28
29 lp[i] = i;
30
31 ip[i+1] = i+1;
32
33 printf("lp[%d]=%d, ip[%d]=%d, ip[j=%d]=%d\n",
34 i, lp[i], i+1, ip[i+1], j, ip[j]);
35
36 return 0;
37 }
Compiling with +check=bounds:pointer:
$ cc +check=bounds:pointer rttest3.c
"rttest3.c", line 34: warning #2549-D: variable "j" is used before its
value is set
76Command-Line Options
i, lp[i], i+1, ip[i+1], j, ip[j]);
^
Catch out-of-bounds pointer access through an uninitialized variable (the uninitialized variable can
be checked by +check=uninit):
$ RTC_NO_ABORT=1 a.out 2
Runtime Error: out of bounds buffer pointed by 0x40010320 has 40 bytes
(variable "a"), reading at 0x40010320-19824, 4 bytes ("rttest3.c", line 33)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out](1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x0000000004003920 main + 0x330 at rttest3.c:33 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Memory fault(coredump)
Check off by one out-of-bounds access:
$ RTC_NO_ABORT=1 a.out 10
Runtime Error: out of bounds buffer pointed by 0x400a1890 has 40 bytes
(allocation stack trace: 0x040035c2, 0x04003612, 0xc0049c42), writing
at 0x400a1890+40, 4 bytes ("rttest3.c", line 29)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x00000000040037b0 main + 0x1c0 at rttest3.c:29 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Runtime Error: out of bounds buffer pointed by 0x40010320 has 40 bytes
(variable "a"), writing at 0x40010320+44, 4 bytes ("rttest3.c", line 31)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x0000000004003810 main + 0x220 at rttest3.c:31 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Runtime Error: out of bounds buffer pointed by 0x400a1890 has 40 bytes
(allocation stack trace: 0x040035c2, 0x04003612, 0xc0049c42), reading
at 0x400a1890+40, 4 bytes ("rttest3.c", line 33)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x00000000040038a0 main + 0x2b0 at rttest3.c:33 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Runtime Error: out of bounds buffer pointed by 0x40010320 has 40 bytes
(variable "a"), reading at 0x40010320+44, 4 bytes ("rttest3.c", line 33)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x00000000040038f0 main + 0x300 at rttest3.c:33 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Runtime Error: out of bounds buffer pointed by 0x40010320 has 40 bytes
(variable "a"), reading at 0x40010320-19824, 4 bytes ("rttest3.c", line 33)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x0000000004003920 main + 0x330 at rttest3.c:33 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Memory fault(coredump)
Check off by any number out-of-bounds access:
Runtime Checking Options77
RTC_NO_ABORT=1 a.out 20
$Runtime Error: out of bounds buffer pointed by 0x40010350 has 10 bytes
(variable "b"), writing at 0x40010350+0, 20 bytes ("memset", line 0)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x00000000040089d0 _rtc_oob_check_unknown_bounds + 0x430 at
rtc_bounds.c:480 [./a.out]
(2) 0x60000000c5f52440 libc_mem_common + 0x280 at infrtc.c:3286
[lib/hpux32/librtc.so]
(3) 0x60000000c5f53650 _memset + 0x80 at infrtc.c:3521
[lib/hpux32/librtc.so]
(4) 0x0000000004003760 main + 0x170 at rttest3.c:27 [./a.out]
(5) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Runtime Error: out of bounds buffer pointed by 0x400a1890 has 40 bytes
(allocation stack trace: 0x040035c2, 0x04003612, 0xc0049c42), writing
at 0x400a1890-2054847100, 4 bytes ("rttest3.c", line 29)
(0) 0x0000000004004770 _rtc_raise_fault + 0x560 at rtc_utils.c:164
[./a.out]
(1) 0x0000000004008790 _rtc_oob_check_unknown_bounds + 0x1f0 at
rtc_bounds.c:465 [./a.out]
(2) 0x00000000040037b0 main + 0x1c0 at rttest3.c:29 [./a.out]
(3) 0x60000000c0049c50 main_opd_entry + 0x50 [/usr/lib/hpux32/dld.so]
Memory fault(coredump)
+check=globals
The +check=globals option enables runtime checks to detect corruption of global variables by
introducing and checking "guards" between them, at the time of program exit. Setting environment
variable RTC_ROUTINE_LEVEL_CHECKwill also enable the check whenever a function compiled
with this option returns.
For this purpose, the definition of global is extended to be all variables that have static storage
duration, including file or namespace scope variables, function scope static variables, and class
(or template class) static data members.
+check=lock
The +check=lock option enables checking of C and C++ user applications that use pthreads.
The option reports violations of locking discipline when appropriate locks are not held while
accessing shared data by different threads. The check is based on the lockset method for detecting
locking discipline violations, as described in the Eraser tool article at http://
Note that +check=all does not enable +check=lock. Also note that since +check=lock
requires instrumenting each memory access, it can result in a considerable slowdown of the
application at runtime. +check=lock also increases the memory consumption of the instrumented
application.
The check is performed on each memory access. It detects violations in locking discipline for mutual
exclusion locks (mutexes) for applications using posix threads. When the locking discipline is
violated, it is reported along with the line number and the address for which the violation occurs.
Consider the following code example:
Runtime Error: locking discipline violation: in file simple_race.c line 16 address 40010658
(0) 0x0000000004072ca0 _rtc_raise_fault + 0x2c0 at rtc_utils.c:382 [./a.out]
(1) 0x0000000004028650 _ZN11DRD_Runtime15HandleMemAccessEybPcjS0_ + 0x590 at lock_check.C:438
[./a.out]
(2) 0x0000000004029840 _ZN11DRD_Runtime17HandleStoreAccessEyPcjS0_ + 0x60 at lock_check.C:145
[./a.out]
(3) 0x000000000401bfa0 __DRD_RegisterStoreAccess__ + 0x160 at lock_check.H:126 [./a.out]
(4) 0x0000000004018780 thread2 + 0xd0 at simple_race.c:16 [./a.out]
(5) 0x60000000c57c3c60 __pthread_bound_body + 0x170
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4512
[/proj/thlo/Compilers/rt/usr/lib/hpux32/libpthread.so.1]
candidate lockset is as follows:
lock1.c line number:23
incoming lockset is as follows:
lock1.c line number:13
In the above message, the candidate lockset refers to the set of locks that are implied to be
associated with the symbol acesss in its previous accesses so far. The incoming lockset refers to
the set of locks that are held at the current access of the symbol. When the intersection between
the candidate lockset and incoming lockset is empty, the checker reports the locking discipline
violation. The candidate lockset and incoming lockset members are specified in terms of the source
file and line number pointing to the pthread_mutex_lock call associated with that lock. For
further details on detecting lock discipline violations, refer to the above-referenced Eraser article.
False positives are possible in certain cases, as mentioned in the Eraser article. Multiple locks can
be used to protect the same shared variable. For example, a linked list can be protected by an
overall lock and an individual entry lock. This can result in the tool reporting a false positive. False
positives might also be reported as a result of memory getting recycled in certain cases because
of deallocations (which the lock checker is not able to detect).
+check=malloc
The +check=malloc option enables memory leak and heap corruption checks at runtime. It will
cause the user program to abort for writes beyond boundaries of heap objects, free or realloc
calls for a pointer that is not a valid heap object, and out-of-memory conditions. Memory leak
information is captured and written out to a log file when the program exits. The name of the logfile
is printed out before program termination.
The +check=malloc option works by intercepting all heap allocation and deallocation calls.
This is done by the use of a debug malloc library, librtc.so. The option works for programs
that use the system malloc or for user provided malloc routines in a shared library. The
librtc.so library is also used by the HP WDB debugger to provide heap memory checking
features in the debugger. Please refer to the HP WDB debugger documentation for more information
about heap memory checking. The librtc.so library is shipped as part of the wdb product.
Runtime Checking Options79
Please install the HP WDB bundled with the compiler or a more recent version of wdb to get full
functionality.
The default behavior of the +check=malloc option can be changed by users providing their own
rtcconfig file. The user specified rtcconfig file can be in the current directory or in a directory
specified by the GDBRTC_CONFIG environment variable. The default configuration used by the
When +check=bounds:pointer is also turned on, it can check freed memory read/write. But
the check needs to retain freed memory which is not turned on by default. To turn on the feature,
set the following environment variable at runtime:
RTC_MALLOC_CONFIG="retain_freed_blocks=1"
Or add "retain_freed_blocks=1" to the rtcconfig file. When malloc failes to allocate specified
memory, the runtime system will free the retained freed memory and try to allocate memory.
For a description for the above configuration parameters and the full list of other parameters,
please refer to the HP WDB debugger documentation.
+check=stack[:frame|:variables|:none]
The +check=stack[:frame|:variables|:none] option enables runtime checks to detect
writes outside stack boundaries. Markers are placed before and after the whole stack frame and
around some stack variables. On procedure exit, a check is done to see if any marker has been
overwritten. If any stack check fails, an error message and stack trace is written to stderr and
the program is aborted. The stack checks are not performed for an abnormal exit from the procedure
(for example, using longjmp, exit, abort, or exception handling).
+check=stack:frame
This option enables runtime checks for illegal writes from the current stack frame that overflow into
the previous stack frame.
+check=stack:variables
This option enables runtime checks for illegal writes to the stack just before or after some variables
on the stack. This includes array, struct/class/union, and variables whose address is taken.
It also includes the overflow check for the stack frame (+check=stack:frame). In addition to
the above checks, this option causes the whole stack to be initialized to a "poison" value, which
can help detect the use of uninitialized variables on the stack.
+check=stack:none
This option disables all runtime checks for the stack.
+check=stack
The +check=stackoption without any qualifiers is equivalent to +check=stack:variables
at optimization levels 0 and 1. It is equivalent to +check=stack:frame for optimization level
2 and above.
+check=thread
The +check=thread option enables the batch-mode thread-debugging features of HP WDB 5.9
or later, and can detect the following thread-related conditions:
•The thread attempts to acquire a nonrecursive mutex that it currently holds.
•The thread attempts to unlock a mutex or a read-write lock that it has not acquired.
•The thread waits (blocked) on a mutex or read-write lock that is held by a thread with a different
scheduling policy.
80Command-Line Options
•Different threads non-concurrently wait on the same condition variable, but with different
associated mutexes.
•The threads terminate execution without unlocking the associated mutexes or read-write locks.
•The thread waits on a condition variable for which the associated mutex is not locked.
•The thread terminates execution, and the resources associated with the terminated thread
continue to exist in the application because the thread has not been joined or detached.
•The thread uses more than the specified percentage of the stack allocated to the thread.
The +check=thread option should only be used with multithreaded programs. It is not enabled
by +check=all.
Users can change the behavior of the +check=thread option by providing their own rtcconfig
file. The user specified rtcconfig file can be in the current directory or in a directory specified
by the GDBRTC_CONFIG environment variable. The default configuration used by the
If any thread error condition is detected during the application run, the error log is output to a file
in the current working directory. The output file will have the following naming convention:
<executable_name>.<pid>.threads
where <pid> is the process id.
+check=truncate[:explicit|:implicit]
The +check=truncate[:explicit|:implicit] option enables runtime checks to detect
data loss in assignment when integral values are truncated. Data loss occurs if the truncated bits
are not all the same as the left most non-truncated bit for signed type, or not all zero for unsigned
type.
Programs might contain intentional truncation at runtime, such as when obtaining a hash value
from a pointer or integer. To avoid runtime failures on these truncations, you can explicitly mask
off the value:
ch = (int_val & 0xff);
Note that the +check=all option does not imply +check=truncate. To enable
+check=truncate, you must explicitly specify it.
+check=truncate:explicit
This option turns on runtime checks for truncation on explicit user casts of integral values, such as
(char)int_val.
+check=truncate:implicit
This option turns on runtime checks for truncation on compiler-generated implicit type conversions,
such as ch = int_val;.
+check=truncate
This option turns on runtime checks for both explicit cast and implicit conversion truncation.
+check=uninit
The +check=uninit option checks for a use of a stack variable before it is defined. If such a
use is detected, an error message is emitted and the program is aborted. The check is done by
adding an internal flag variable to track the definition and use of user variables.
Runtime Checking Options81
If the +check=bounds:pointer is on, +check=uninit will check pointer access for uninitialized
memory read (UMR). To enable checking, the runtime system will initialize the heap objects and
stack variables with a special pattern. If the pointer accesses an area containing the specified
pattern for the specified length, then it assumes the read is UMR. To minimize UMR false positive,
the user may change the special pattern and number of bytes to check by using RTC_UMR
environment variable:
RTC_UMR=[INIT=0xnn][:CHECK_SIZE=sz]
where:
•INIT specifies the char type value used to initialize heap/local objects. The default pattern is
0xDE.
•CHECK_SIZE specifies the minimum number of bytes used to check for UMR. The default
number is 2.
Also see the +Oinitcheck option to enable compile-time warnings for variables that may be
used before they are set.
Standards Related Options
The compiler accepts the following options related to the ANSI/ISO 9899-1990 Standard for the
C Programming Language, the ANSI/ISO International Standard, and ISO/IEC 14882 Standard
for the C++ Programming Language:
-Aa
-AA
-Aa
The -Aa option instructs the compiler to use Koenig lookup and strict ANSI for scope rules. This
option is equivalent to specifying -Wc,-koenig_lookup,on and -Wc,-ansi_for_scope,on.
The default is on for C++, but off for C. Refer to the -Ae option for C-mode description. The
standard features enabled by -Aa are incompatible with earlier C and C++ features.
-AA
The -AA option enables the use of the new 2.0 Standard C++ Library, which includes the new
standard conforming (templatized) iostream library. It conforms to the ISO C++ standard.
The –AA option sets -Wc,-koenig_lookup,on and -Wc,-ansi_for_scope,on, and is the
default C++ compilation mode.
Usage:
The standard features enabled by -AA are incompatible with the older Rogue Wave Standard
C++ Library 1.2.1 and Tools.h++ 7.0.6. All modules must be consistent in using -AA. Mixing
modules compiled with -AA with ones that are not is not supported.
NOTE:
•This option is not supported in legacy HP C. This option is ignored with warnings in C-mode.
•This option will be removed in a future version of the compiler. Use the equivalent option
+std=c++98 to ensure that your builds do not break in future.
-Aarm
-Aarm
NOTE:This option was deprecated earlier and is obsolete in this release.
82Command-Line Options
-AC89
-AC99
This option enables the Tru64 UNIX C++ Annotated Reference Manual (ARM) dialect. This dialect
was the default for Tru64 UNIX C++ compilers through compiler version 5.x. Support of this dialect
is intended only to ease porting of existing Tru64 UNIX applications to HP-UX, and not for
development of new programs.
For more information on the ARM dialect, refer to the The Annotated C++ Reference Manual,
(Margaret A. Ellis and Bjarne Stroustrup, Addison-Wesley, ISBN 0-201-51459-1, 1990).
-AC89
The -AC89 option invokes the compiler in ANSI C89 compilation mode. This option, when specified
with the -ext option, invokes a part of ANSI C99 features.
NOTE:This option will be removed in a future version of the compiler. Use the equivalent option
+std=c89 to ensure that your builds do not break in future.
-AC99
The -AC99 option invokes the compiler in ANSI C99 compilation mode with its features. This is
the default C compilation mode, and the following commands are equivalent:
cc
cc -Ae
cc -AC99
aCC -Ae
aCC -AC99
-Ae
-Ag++
NOTE:This option will be removed in a future version of the compiler. Use the equivalent option
+std=c99 to ensure that your builds do not break in future.
-Ae
Setting the -Ae option invokes aC++ as an ANSI C compiler, with additional support for HP C
language extensions.
This option is a synonym for the -AC99 option.
For C++, if -Ae is anywhere on the command line, C-mode will be in effect. The options, -AA and
-AP, are ignored with warnings. If both -Ae and -Aa are present, C-mode will be in effect and
the right most option determines whether extended ANSI (-Ae) or strict ANSI (-Aa) is in effect. To
get strict ANSI, both -Ae and -Aa option are required.
NOTE:Some code that is a warning in C may be a fatal error in HP aC++.
This option enables GNU C++ dialect compatibility. Not all GNU features are available, for
instance, the asm mechanism. See also “-fshort-enums ” (page 35).
NOTE:This option will be removed in a future version of the compiler. Use the equivalent option
+std=g++ to ensure that your builds do not break in future.
-Agcc
This option enables GNU C dialect compatibility. Not all GNU features are available, for instance,
the asm mechanism. See also “-fshort-enums ” (page 35).
Standards Related Options83
NOTE:
•For HP aC++, the -Ae option must also be used.
•This option will be removed in a future version of the compiler. Use the equivalent option
+std=gcc to ensure that your builds do not break in future.
-AOa and -AOe
-AOa
-AOe
See the following C mode options:
•“-Aa” (page 82)
•“-Ae” (page 83)
In addition to specifying the ANSI C language dialect, allows the optimizer to aggressively exploit
the assumption that the source code conforms to the ANSI programming language C standard ISO9899:1990.
At present, the effect is to make +Otype_safety=ansi the default. As new
independently-controllable optimizations are developed that depend on the ANSI C standard, the
flags that enable those optimizations may also become the default under -AOa or -AOe.
-AP
-AP
NOTE:To enable future runtime library versions, this option was deprecated earlier and is
obsolete in this release. If there is a build using this option, migrate your source to comply with the
C++ ANSI standard.
The -AP option turns off -AA mode and uses the older C++ runtime libraries.
NOTE:This option is not supported in legacy HP C. This option is ignored with warnings in
C-mode.
-Ax
The -Ax option turns on support for several core language features introduced by the recently
published C++11 standard. The -Ax option is available only in C++ compilation mode and is
binary compatible with the -AA compilation mode. See the HP aC++/HP ANSI C Release Notes
for a description of extensions supported.
NOTE:This option will be removed in a future version of the compiler. Use the equivalent option
+std=c++11 to ensure that your build does not break in future.
+legacy_cpp
+legacy_cpp
The +legacy_cpp option enables the use of cpp.ansi ANSI C preprocessor. This option is
available in C-mode only.
NOTE:This option is not normally needed and may be deprecated in future.
+legacy_v5
+legacy_v5
This option enables the use of the A.05.60 compiler. The default compiler is the A.06.00 compiler.
84Command-Line Options
+std=c89|c99|c++98|c++11|gcc|g++|gnu
+std=c89: This option invokes the compiler in ANSI C89 compilation mode. This option when
specified with the -ext option, it invokes a part of ANSI C99 feature. This is equivalent to the
'–AC89' option.
+std=c99: This option invokes the compiler in ANSI C99 compilation mode with its features. This
is the default C compilation mode. This is equivalent to the '–AC99' option.
+std=c++98: This option invokes the compiler in ISO C++98 standard mode. This is the default
C++ compilation mode and this is equivalent to the '–AA' option.
+std=c++11: This option turns on support for several core language features introduced by the ISO
C++11 language standard. It is available only in C++ compilation mode and is binary compatible
with the '+std=c++98' ('–AA') compilation mode.
+std=gcc: This option enables GNU C dialect compatibility. This option is equivalent to '–Agcc'
option.
+std=g++: This option enables GNU C++ dialect compatibility. This option is equivalent to '–Ag++'
option.
+std=gnu: This command line option is also used to enable gnu dialects. It switches between
'+std=gcc ' or '+std=g++' compilation, depending on whether the compilation mode is C or C++
respectively.
+stl=rw|none
+stl=rw: This option is used to specify RogueWave STL 2.0 implementation. This option is equivalent
to ‘–AA’ option. It includes C++98 compliant standard template library. This is the default STL.
This option causes standard C++ header files to be picked up from the directory
'/opt/aCC/include_std' and is linked with libstd_v2.so.
+stl=none: By eliminating references to the standard header files and libraries bundled with HP
C++ compiler, this option allows experienced users to have full control over the header files and
libraries used in compilation and linking of their applications. This is equivalent to ‘+nostl’ option.
Standards Related Options85
+tru64
+tru64
This option causes return types of unprototyped functions to be treated as long, instead of int,
matching Tru64 C behavior. This can prevent segfaults in +DD64 mode, resulting from pointer
truncation, for instance:
long *a;
long sub() {
a = malloc(sizeof(long)); /* no prototype! */
*a = 1234; /* segfault if +DD64 and no +tru64 */
return *a;
}
A preferable solution is to provide the appropriate function prototypes.
NOTE:This option is applicable to C language only.
-Wc,-ansi_for_scope,[on|off]
-Wc,-ansi_for_scope,[on|off]
The -Wc,-ansi_for_scope is option enables or disables the standard scoping rules for init
declarations in for statements; the scope of the declaration then ends with the scope of the loop
body. By default, the option is disabled.
Examples:
In the following example, if the option is not enabled (the current default), the scope of k extends
to the end of the body of main and statement (1) is valid (and will return zero). With the option
enabled, k is no longer in scope and (1) is an error.
#include <stdio.h>
int main() {
for (int k = 0; k!=100; ++k) {
printf(“%d\n”, k);
}
return 100-k; // (1)
}
In the next example, with the option disabled, the code is illegal, because it redefines k in (2)
when a previous definition (1) is considered to have occurred in the same scope.
With the option enabled (-Wc,-ansi_for_scope,on), the definition in (1) is no longer in scope
at (2) and thus the definition in (2) is legal.
int main() {
int sum = 0;
for (int k = 0; k!=100; ++k) // (1)
sum += k;
for (int k = 100; k!= 0; ++k) // (2)
sum += k;
}
-Wc,-koenig_lookup,[on|off]
-Wc,-koenig_lookup,[on|off]
The -WC,-koenig_lookup option enables or disables standard argument-dependent lookup
rules (also known as Koenig lookup). It causes functions to be looked up in the namespaces and
classes associated with the types of the function-call argument. By default, the option is enabled.
Example:
In the following example, if the option is not enabled, the call in main does not consider declaration
(1) and selects (2). With the option enabled, both declarations are seen, and in this case overload
resolution will select (1).
86Command-Line Options
namespace N {
struct S {};
void f(S const&, int); // (1)
}
void f(N::S const&, long); // (2)
int main() {
N::S x;
f(x, 1);
}
Subprocesses of the Compiler
These options allow you to substitute your own processes in place of the default HP aC++
subprocesses, or pass options to HP aC++ subprocesses.
-tx,name
-tx,name
The -tx,name option substitutes or inserts subprocess x, using name.
The parameter, x, is one or more identifiers indicating the subprocess or subprocesses. The value
of x can one or more of the following:
Table 8 Identifiers
Descriptionx
Assembler (standard suffix is as)a
Compiler (standard suffix is ctcom/ecom)c
Same as cC
Filter tool (standard suffix is c++filt)f
Linker (standard suffix is ld)l
Preprocessor (standard suffix is cpp.ansi).p
-tp must be used before any -Wp options can be passed to cpp.ansi. To enable the external
preprocessor, use:
-tp,/opt/langtools/lbin/cpp.ansi.
Stand-alone code generator (standard suffix is u2comp)u
All subprocessesx
The -tx,name option works in two modes:
1.If x is a single identifier, name represents the full path name of the new subprocess.
2.If x is a set of identifiers, name represents a prefix to which the standard suffixes are
concatenated to construct the full path names of the new subprocesses.
For example, the following command invokes the assembler /users/sjs/myasmb instead of the
default assembler /usr/ccs/bin/as to assemble and link file.s.
aCC -ta,/users/sjs/myasmb file.s
More Examples of -t
Following are some examples of -t option:
•Substituting for C++ file:
The following example compiles file.C and specifies that /new/bin/c++filt should be
used instead of the default /opt/aCC/bin/c++filt.
Subprocesses of the Compiler87
•Substituting for ecom:
•Substituting for all Subprocesses:
-Wx,args
-Wx,arg1[,arg2,..,argn]
The -Wx,args option passes the arguments arg1 through argn to the subprocess x of the
compilation.
Each argument, arg1, arg2, through argn takes the form:
-argoption[,argvalue]
where:
aCC -tf,/new/bin/c++filt file.C
The following example compiles file.C and specifies that /users/proj/ecom should be
used instead of the default /opt/aCC/lbin/ecom.
aCC -tC,/users/proj/ecom file.C
The following example compiles file.C and specifies that the characters /new/aCC should
be used as a prefix to all the subprocesses of HP aC++. For example, /new/aCC/ecom runs
instead of the default /opt/aCC/lbin/ecom.
aCC -tx,/new/aCC file.C
•argoption is the name of an option recognized by the subprocess.
•argvalue is a separate argument to argoption, where necessary.
The parameter, x, is one or more identifiers indicating a subprocess or subprocesses. The value
of x can be one or more of the following:
Table 9 Identifiers
Descriptionx
Assembler (standard suffix is as)a
Compiler (standard suffix is ecom)c
Same as cC
Filter tool (standard suffix is c++filt)f
Linker (standard suffix is ld)l
Preprocessor (standard suffix is cpp.ansi).p
-tp must be used before any -Wp options can be passed to cpp.ansi. To enable the external
preprocessor, use:
-tp,/opt/langtools/lbin/cpp.ansi.
Stand-alone code generator (standard suffix is u2comp)u
All subprocessesx
Example:
The following example compiles file.C and passes the option -v to the linker.
aCC -Wl,-v file.C
88Command-Line Options
Passing Options to the Linker with -W
The following example links file.o and passes the option -a archive to the linker, indicating
that the archive version of the math library (indicated by -lm) and all other driver-supplied libraries
should be used rather than the default shared library:
aCC file.o -Wl,-a,archive -lm
Passing Multiple Options to the Linker with -W
The following example links file.o and passes the options -a , archive, -m, and -v to the
linker:
aCC -Wl,-a,archive,-m,-v file.o -lm
This case is similar to the previous example, with additional options. -m indicates that a load map
should be produced. The -v option requests verbose messages from the linker.
Symbol Binding Options
The following -B options are recognized by the compiler to specify whether references to global
symbols may be resolved to symbols defined in the current load module, or whether they must be
assumed to be potentially resolved to symbols defined in another load module.
A global symbol is one that is visible by name across translation unit boundaries. A static symbol
is one that is visible by name only within a single translation unit but is not associated with a
particular procedure activation. A locally defined symbol is a global or static symbol with a
definition in the translation unit from which it is being referenced.
-Bdefault
-Bextern
-Bdefault
Global symbols are assigned the default export class. These symbols may be imported or exported
outside of the current load module. The compiler will access tentative and undefined symbols
through the linkage table. Any symbol that is not assigned to another export class through use of
another -B option will have the default export class. The -Bdefault option may also be used
on a per symbol basis to specify exceptions to global -Bprotected, -Bhidden, and -Bextern
options.
Usage:
-Bdefault=symbol[,symbol...]
The named symbols are assigned the default export class.
-Bdefault:filename
The file indicated by filename contains a list of symbols, separated by spaces or newlines. These
symbols are assigned the default export class.
-Bextern
The specified symbols, or all undefined symbols if no list is provided, are assigned to default export
class. Additionally, the compiler will inline the import stub for calls to these symbols. No compile
time binding of these symbols will be done. All references to these symbols will be through the
linkage table, so an unnecessary performance penalty will occur if -Bextern is applied to a listed
symbol that is resolved in the same load module.
Usage:
-Bextern=symbol[,symbol...]
The named symbols, or all symbols if no list is provided, are assigned the default export class. Use
of list form overrides the default binding of locally defined symbols.
Symbol Binding Options89
-Bextern:filename
The file indicated by filename is expected to contain a list of symbols, separated by spaces or
newlines. These symbols are assigned the default export class.
-Bhidden
-Bhidden
The specified symbols, or all symbols if no symbols are specified, are assigned the hidden export
class. The hidden export class is similar to the protected export class. In addition, hidden symbols
will not be exported outside the current load module. The linker may eliminate them from a shared
library, but in an executable, they remain accessible to the debugger unless +Oprocelim is also
specified.
When used with no symbol list, -Bhidden implies -Wl,-aarchive_shared, causing the linker
to prefer an archive library over a shared library if one is available. This can be overridden by
following the -Bhidden option with a subsequent -Wl,-a option.
Usage:
-Bhidden=symbol[,symbol...]
The named symbols, or all symbols if no symbols are specified, are assigned the hidden export
class.
-Bhidden:filename
The file indicated by filename is expected to contain a list of symbols separated by spaces or
newlines. These symbols are assigned the hidden export class.
-Bhidden_def
-Bhidden_def
This option is the same as -Bhidden, but only locally defined (non-tentative) symbols, without
__declspec(dllexport), are assigned the hidden export class.
-Bprotected
-Bprotected[=symbol[,symbol...]]
The specified symbols, or all symbols if no symbols are specified, are assigned the protected export
class. That means these symbols will not be preempted by symbols from other load modules, so
the compiler may bypass the linkage table for both code and data references and bind them to
locally defined code and data symbols.
When used with no symbol list, -Bprotected implies -Wl,-aarchive_shared, causing the
linker to prefer an archive library over a shared library, if one is available. This can be overridden
by following the -Bprotected option with a subsequent -Wl,-a option.
Usage:
-Bprotected:filename
The file indicated by filename contains a list of symbols, separated by spaces or newlines. These
symbols are assigned the protected export class.
-Bprotected_data
-Bprotected_data
The -Bprotected_data option marks only data symbols as having the protected export class.
-Bprotected_def
-Bprotected_def
90Command-Line Options
The -Bprotected_def option is the same as -Bprotected but only locally defined (non-tentative)
symbols are assigned the protected export class.
-Bsymbolic
-Bsymbolic
The -Bsymbolic option assigns protected export class to all symbols. This is equivalent to
-Bprotected with no symbol list.
NOTE:This option is deprecated as of version A.06.05 and if used, it issues a warning that
-Bprotected_defis almost always what should be used in its place.
Template Options
By using a template option on the aCC command line, you can:
•Close a library or set of link units, to satisfy all unsatisfied instantiations without creating
duplicate instantiations.
•Specify what templates to instantiate for a given translation unit.
•Name and use template files in the same way as for the cfront based HP C++ compiler.
•Request verbose information about template processing.
NOTE:All template options on an aCC command line apply to every file on the command line.
If you specify more than one incompatible option on a command line, only the last option takes
effect.
+[no]dep_name
The +[no]dep_name option enforces strict dependent-name lookup rules in templates. The default
is +dep_name.
+inst_compiletime
+inst_compiletime
The +inst_compiletime option causes the compiler to use the compile time (CTTI) instantiation
mechanism to instantiate templates. This occurs for every template used or explicitly instantiated
in this translation unit and for which a definition exists in the translation unit. This is the default.
NOTE:This option is supported in C++ only and ignored in C-mode.
+inst_directed
+inst_directed
The +inst_directed option indicates to the compiler that no templates are to be instantiated
(except explicit instantiations). If you are using only explicit instantiation, specify +inst_directed.
The following example compiles file.C with the resulting object file containing no template
instantiations, except for any explicit instantiations coded in your source file.
aCC +inst_directed prog.C
See Chapter 5: “Using HP aC++ Templates” (page 132) for more information.
NOTE:This option is supported in C++ only and ignored in C-mode.
+inst_implicit_include
+inst_implicit_include
Template Options91
The +inst_implicit_include option specifies that the compiler use a process similar to that
of the cfront source rule for locating template definition files. For the cfront based HP C++
compiler, if you are using default instantiation (that is, if you are not using a map file), you must
have a template definition file for each template declaration file, and these must have the same
file name prefix.
This restriction does not apply in HP aC++. Therefore, if your code was written for HP C++ and
you wish to follow this rule when compiling with HP aC++, you need to specify the
+inst_implicit_include option.
This option is strongly discouraged and the sources should be modified to conform to the standard.
Example:
aCC +inst_implicit_include prog.C
If prog.C includes a template declaration file named template.h, the compiler assumes a
template definition file name determined by the +inst_include_suffixes option.
See Chapter 5: “Using HP aC++ Templates” (page 132) for more information.
NOTE:This option is supported in C++ only and ignored in C-mode.
+inst_include_suffixes
+inst_include_suffixes "list"
The +inst_include_suffixes option specifies the file name extensions that the compiler uses
to locate template definition files. This option must be used with the +inst_implicit_include
option.
list is a set of space separated file extensions or suffixes, enclosed in quotes, that template
definition files can have.
The default extensions in order of precedence are:
•.c
•.C
•.cxx
•.CXX
•.cc
•.CC
•.cpp
User-specified extensions must begin with a dot and must not exceed four characters in total. Any
extension that does not follow these rules causes a warning and is ignored.
These restrictions do not apply in HP aC++. Therefore, if your code was written for HP C++ and
you wish to follow the cfront-based HP C++ template definition file naming conventions when
compiling with HP aC++, you need to specify the +inst_include_suffixes option.
The following example specifies that template definition files can have extensions of .c or .C:
+inst_include_suffixes ".c .C"
The +inst_include_suffixes option is equivalent to the HP C++ -ptS option.
See Chapter 5: “Using HP aC++ Templates” (page 132) for more information.
NOTE:This option is supported in C++ only and ignored in C-mode.
Trigraph Processing Suppression Option
The -notrigraphoption suppresses trigraph processing.
92Command-Line Options
-notrigraph
The-notrigraph option inhibits the processing of trigraphs. In previous versions,
[LINEBREAK]-notrigraph caused the legacy preprocessor to be invoked. Though this ignored
trigraphs, trigraphs were still interpreted by the compiler in the preprocessed source. The -notrigraph
option no longer invokes the legacy preprocessor, and also suppresses trigraphs from being
interpreted.
This option is not recommended. The proper portable solution is to quote the "?" as "\?".
Verbose Compile and Link Information
Use the following options to obtain additional information about:
•The HP compiler actions while compiling or linking your program.
•The subprocesses executed for a given command line, without running the compiler.
•The current compiler and linker version numbers.
•The Execution time.
-dumpversion
-dumpversion
The +dumpversion option displays the simple version number of the compiler, such as A.06.25.
Compare with the -V option, which displays more verbose product version information.
+dryrun
+dryrun
The +dryrun option generates subprocess information for a given command line without running
the subprocesses. It is useful in the development process to obtain command lines of compiler
subprocesses in order to run the commands manually or to use them with other tools.
Example:
The following command line gives the same kind of information as the -v option, but without
running the subprocesses.
aCC +dryrun app.C
+O[no]info
+O[no]info
The +Oinfo option displays informational messages about the optimization process. This option
may be helpful in understanding what optimizations are occurring. You can use the option at levels
0-4. The default is +Onoinfo at levels 0-4.
+wsecurity
+wsecurity[={1|2|3|4}]
The +wsecurity option can take an argument to control how verbosely the security messages
are emitted. The default level is 2.
+time
+time
The +time option generates timing information for compiler subprocesses. For each subprocess,
estimated time is generated in seconds for user processes, system calls, and total processing time.
This option is useful in the development process, for example, when tuning an application’s
compile-time performance.
Verbose Compile and Link Information93
Examples:
•The aCC +time app.C command generates the following information:
-----------------------------------------total link time(user+sys): 0.59
removing /usr/tmp/AAAa28149
removing app.o
-v
-V
-v
The -v option enables verbose mode, sending a step-by-step description of the compilation process
to stderr. This option is especially useful for debugging or for learning the appropriate commands
for processing a C++ file.
Example:
The aCC -v file.C command compiles file.C and gives information about the process of
compiling.
The -V option displays the version numbers of the current compiler and linker (if the linker is
executed). Use this option whenever you need to know the current compiler and linker version
numbers.
Example:
94Command-Line Options
aCC -V app.C
aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]
ld: 92453-07 linker ld HP Itanium(R) B.12.24 PBO 040820 (IPF/IPF)
Concatenating Options
You can concatenate some options to the aCC command under a single prefix. The longest substring
that matches an option is used. Only the last option can take an argument. You can concatenate
option arguments with their options if the resulting string does not match a longer option.
Examples:
Suppose you want to compile my_file.C using the options -v and -g1. Below are equivalent
command lines you can use:
•aCC my_file.C -v -g1
•aCC my_file.C -vg1
•aCC my_file.C -vg1
•aCC -vg1 my_file.C
Concatenating Options95
3 Pragma Directives and Attributes
A pragma directive is an instruction to the compiler. You use a #pragma directive to control the
actions of the compiler in a particular portion of a translation unit without affecting the translation
unit as a whole.
Put pragmas in your C++ source code where you want them to take effect. Unless otherwise
specified, a pragma is in effect from the point where it is included until the end of the translation
unit or until another pragma changes its status.
This chapter discusses the following pragma directives:
•“Initialization and Termination Pragmas” (page 96)
•“Copyright Notice and Identification Pragmas” (page 97)
•“Data Alignment Pragmas” (page 98)
•“Optimization Pragmas” (page 103)
•“Diagnostic Pragmas” (page 105)
•“Other Pragmas” (page 105)
•“OpenMP Clauses” (page 114)
•“Attributes” (page 116)
Initialization and Termination Pragmas
INIT
FINI
This section describes the INIT and FINI pragmas. These pragmas allow the user to set up
functions which are called when a load module (a shared library or executable) is loaded (initializer)
or unloaded (terminator).
For example, when a program begins execution, its initializers get called before any other user
code gets called. This allows some set up work to take place. In addition, when the user’s program
ends, the terminators can do some clean up. When a shared library is loaded or unloaded, its
initializers and terminators are also executed at the appropriate time.
#pragma INIT “string”
Use #pragma INIT to specify an initialization function. The function takes no arguments and
returns nothing. The function specified by the INIT pragma is called before the program starts or
when a shared library is loaded. For example,
#pragma INIT "my_init"
void my_init() { ... do some initializations ... }
#pragma FINI “string”
Use #pragma FINI to specify a termination function. The function specified by the FINI pragma
is called after the program terminates by either calling the libc exit function, returning from
the main or _start functions, or when the shared library, which contains the FINI is unloaded
from memory. Like the function called by the INIT pragma, the termination function takes no
arguments and returns nothing. For example,
#pragma FINI "my_fini"
void my_fini() { ... do some clean up ... }
96Pragma Directives and Attributes
Copyright Notice and Identification Pragmas
The following pragmas can be used to insert strings in code.
COPYRIGHT
#pragma COPYRIGHT "string”
string is the set of characters included in the copyright message in the object file.
The COPYRIGHT pragma specifies a string to include in the copyright message and puts the
copyright message into the object file.
If no date is specified (using pragma COPYRIGHT_DATE), the current year is used in the copyright
message. For example, assuming the year is 1999, the directive #pragma COPYRIGHT "Acme
Software" places the following string in the object code:
(C) Copyright Acme Software, 1999. All rights reserved. No part of this
program may be photocopied, reproduced, or transmitted without prior
written consent of Acme Software.
The following pragmas
#pragma COPYRIGHT_DATE "1990-1999"
#pragma COPYRIGHT "Brand X Software"
place the following string in the object code:
(C) Copyright Brand X Software, 1990-1999. All rights reserved. No part
of this program may be photocopied, reproduced, or transmitted without
prior written consent of Brand X Software.
COPYRIGHT_DATE
#pragma COPYRIGHT_DATE "string"
string is a date string used by the COPYRIGHT pragma.
This pragma specifies a date string to be included in the copyright message.
Use the COPYRIGHT pragma to put the copyright message into the object file.
For example, #pragma COPYRIGHT_DATE "1988-1992" places the string "1988-1992" in
the copyright message.
LOCALITY
#pragma LOCALITY "string"
string specifies a name to be used for a code section.
The LOCALITY pragma specifies a name to be associated with the code written to a relocatable
object module. The string is forced to be uppercase in C.
All code following the LOCALITY pragma is associated with the name specified in string. Code
that is not headed by a LOCALITY pragma is associated with the name .text.
The smallest scope of a unique LOCALITY pragma is a function.
For example, the directive,
#pragma LOCALITY "MINE"
builds the name .text.MINE and associates all code following this pragma with this name, unless
another LOCALITY pragma is encountered.
LOCALITY_ALL
#pragma LOCALITY_ALL string
Copyright Notice and Identification Pragmas97
The LOCALITY_ALL pragma specifies a name to be associated with the linker procedures and
global variables that should be grouped together at program binding or load time.
These are written to a relocatable object module. All procedures and global variables following
the LOCALITY_ALL pragma are associated with the name specified in the string.
VERSIONID
#pragma VERSIONID "string"
string is a string of characters that HP aC++ places in the object file.
The VERSIONID pragma specifies a version string to be associated with a particular piece of
code. The string is placed into the object file produced when the code is compiled.
For example, the directive
#pragma VERSIONID "Software Product, Version 12345.A.01.05"
places the characters Software Product, Version 12345.A.01.05 into the object file.
Data Alignment Pragmas
This section discusses the data alignment pragmas and their various arguments available on HP-UX
systems to control alignment across platforms.
ALIGN
#pragma align N
PACK
N is a number raised to the power of 2.
HP aC++ supports user-specified alignment for global data. The pragma takes effect on next
declaration. If the align pragma declaration is not in the global scope or if it is not a data
declaration, the compiler displays a warning message. If the specified alignment is less than the
original alignment of data, a warning message is displayed, and the pragma is ignored. Note
that for C code you must initialize the variables, otherwise the compiler will generate a warning.
#pragma align 2
char c; // "c" is at least aligned on 2 byte boundary.
#pragma align 64
int i, a[10]; // "i" and array "a" are at least aligned 64 byte boundary.
// the size of "a" is still 10*sizeof(int)
#pragma PACK [n]|[push|pop]|[,<name>][,n]|show]
n can be 1, 2, 4, 8, or 16 bytes. If n is not specified, maximum alignment is set to the default
value.
This file-scoped pragma allows you to specify the maximum alignment of class fields. The alignment
of the whole class is then computed as usual, to the alignment of the most aligned field in the class.
NOTE:The result of applying #pragma pack n to constructs other than class definitions
(including struct definitions) is undefined and not supported. For example:
#pragma pack 1
int global_var; // Undefined behavior: not a class definition
void foo() { // Also undefined
}
Example:
struct S1 {
char c1; // Offset 0, 3 bytes padding
98Pragma Directives and Attributes
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S1)==12, alignment 4
#pragma pack 1
struct S2 {
char c1; // Offset 0, no padding
int i; // Offset 1, no padding
char c2; // Offset 5, no padding
}; // sizeof(S2)==6, alignment 1
// S3 and S4 show that the pragma does not affect class fields
// unless the class itself was defined under the pragma.
struct S3 {
char c1; // Offset 0, no padding
S1 s; // Offset 1, no padding
char c2; // Offset 13, nopadding
}; // sizeof(S3)==14, alignment 1
struct S4 {
char c1; // Offset 0, no padding
S2 s; // Offset 1, no padding
char c2; // Offset 7, no padding
}; // sizeof(S4)==8, alignment 1
#pragma pack
struct S5 { // Same as S1
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S5)==12, alignment 4
#pragma pack (push, my_new_align, 1)
struct S6 { // Same as S2
char c1; // Offset 0, no padding
int i; // Offset 1, no padding
char c2; // Offset 5, no padding
}; // sizeof(S6)==6, alignment 1
#pragma pack 2
#pragma pack show // compiler diagnostic
// that shows current
// pragma pack setting
#pragma pack (pop, my_new_align)
struct S8 { // Same as S1
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S8)==12, alignment 4
The pack pragma may be useful when porting code between different architectures where data
type alignment and storage differences are of concern. Refer to the following examples:
Data Alignment Pragmas99
Basic Example
The following example illustrates the pack pragma and shows that it has no effect on class fields
unless the class itself was defined under the pragma:
struct S2 {
char c1; // Offset 0, no padding
int i; // Offset 1, no padding
char c2; // Offset 5, no padding
}; // sizeof(S2)==6, alignment 1
// S3 and S4 show that the pragma does not affect class fields
// unless the class itself was defined under the pragma.
struct S3 {
char c1; // Offset 0, 3 bytes padding
S1 s; // Offset 4, no padding
char c2; // Offset 16, 3 bytes padding
}; // sizeof(S3)==20, alignment 4
struct S4 {
char c1; // Offset 0, no padding
S2 s; // Offset 1, no padding
char c2; // Offset 7, no padding
}; // sizeof(S4)==8, alignment 1
#pragma pack
struct S5 { // Same as S1
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S5)==12, alignment 4
Template Example
If the pragma is applied to a class template, every instantiation of that class is influenced by the
pragma value in effect when the template was defined. For example: