Legal Notices
Copyright (C) Hewlett-Packard Company 2002. All rights are reserved.
Reproduction, adaptation, or translation without prior written permission
is prohibited, except as allowed under the copyright laws.
Hewlett-Packard makes no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be liable for errors contained herein nor direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Information in this publication is subject to change without notice.
Corporate Offices: Hewlett-Packard Co., 3000 Hanover St., Palo Alto, CA 94304
Use, duplication or disclosure by the U.S. Government Department of Defense is subject to restrictions as set forth in paragraph (b)(3)(ii) of the Rights in Technical Data and Software clause in FAR 52.227-7013.
Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2).
Use of this document and flexible disc(s), compact disc(s), or tape
cartridge(s) supplied for this pack is restricted to this product only.
Additional copies of the programs may be made for security and back-up
purposes only. Resale of the programs in their present form or with alterations,
is expressly prohibited.
A copy of the specific warranty terms applicable to your Hewlett-Packard product and replacement parts can be obtained from your local Sales and Service Office.
(C) Copyright 1980, 1984, 1986 AT&T Technologies, Inc. UNIX and System V are registered trademarks of AT&T in the USA and other countries. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.
PostScript is a trademark of Adobe Systems, Inc.
(C) Copyright 1985-1986, 1988 Massachusetts Institute of Technology.
X Window System is a trademark of the Massachusetts Institute of Technology.
_____________________________________________________________________________________________________
Unless describing a C++ specific feature or capability, the material provided here covers the C++ as well as ANCI C compilers.
This document resides online in the following locations:
For the aC++ compiler:
/opt/aCC/newconfig/RelNotes/ACXX.release.notesFor the ANSI C compiler:
/opt/ansic/newconfig/RelNotes/ACXX.release.notesTo print this file, use an lp command like the following:
For the aC++ compiler:
lp -dprinter_name /opt/aCC/newconfig/RelNotes/ACXX.release.notesFor the ANSI C compiler:
lp -dprinter_name /opt/ansic/newconfig/RelNotes/ACXX.release.notesFor the current version of the compilers and their documentation, use your browser to access the HP aC++ compiler and ANSI C compiler home pages.
For the aC++ compiler:
http://www.hp.com/go/cpp
For the ANSI C compiler:
http://www.hp.com/go/c
_____________________________________________________________________________________________________
The HP aC++ compiler of this IPF release combines aC++ and C compiler
in one. It provides a common ANSI C/C++ compiler with a very high
level of compatibility with the previous release of the HP C compiler.
The main goal of this release is to actively drive the migration
of ANSI C based HP-UX S/W base from HP C to aC++ compiler with ease.
The new HP C compiler has a very few incompatibilities with its previous release version. These incompatibilities have minimum or no impact on the applications that are migrated to the IPF platform.
The differences are:
- no support for "-Ac" (K&R) mode
- no support for MPE long pointers (^)
- no support for the standalone C tools:
(lint, cb, cflow, cxref, endif, protogen)
- no support for the HP_ALIGN pragma (MPE alignments)
This section summarizes the features included in this version of the HP aC++/ HP ANSI C Itanium Processor Family (IPF) compiler. The aC++ compiler supports much of the ISO/IEC 14882 Standard for the C++ Programming Language (the international standard for C++). The ANSI C compiler supports ANSI ISO/IEC 9899:1990.
HP aC++/HP ANSI C provides a variety of performance related options, in addition to the options described in this release notes. See the "HP aC++ Online Programmer's Guide" "Performance" section for full documentation. Chapter 3 of this release notes provides access instructions to the guide.
See "Command Line Options and Pragmas" section in the HP aC++ Online Programmer's Guide for more information.
The current compiler supports only ASCII strings or characters (8 bit chars with no transliteration) as UTF-16.
Any string or character which is preceded by 'u' is recognized as a UTF-16 literal or character and is stored as an unsigned short type.
Example:
#define _UTF16(x) u##x #define UTF16(y) _UTF16(#y) typedef unsigned short utf16_t; utf16_t *utf16_str = UTF16(y); // u"y" int size = sizeof(u't'); // size of 2 bytes
To enable recognition of OpenMP pragmas, use the "+Oopenmp" command line option when invoking aCC. This option is effective at any optimization level.
Note: Currently +Onoparallel does not affect the OpenMP pragmas in the source but still disables +Oautopar.
OpenMP programs require the libomp and libcps runtime support libraries to be present on both the compilation and runtime system(s). The compiler driver will automatically include them when linking.
It is recommended that you use the -N option when linking OpenMP programs to avoid exhausting memory when running with large numbers of threads.
For this first release of aCC containing OpenMP, some debugging position information for OpenMP constructs may not be accurate. In addition, symbols marked with the "threadprivate" pragma may not be visible to the debugger. To work around this limitation, use the "__thread" storage class specifier in the symbol declaration instead.
#if defined(__HP_aCC) && !defined(__THREAD) # define __THREAD #endif
__THREAD int tprvt; #pragma omp threadprivate(tprvt)along with the command line:
aCC -D__THREAD=__threadOpenMP is also supported in HP C and aC++'s ANSI C mode (-Ae).
SDKROOT
TARGETROOT
The SDKROOT environment variable is used as a prefix for all references
to tool set components and must be set when you use
a non-native development kit or a toolset installed at an alternative
location. Some of the toolset components are compiler
drivers, Compiler Applications, Preprocessor, Linker, and object file
tools.
Example:
If a compiler tool set is installed in directory /opt/xdk-ia/ then,
export SDKROOT=/opt/xdk-iaprefixes all references to the compiler tool set components with /opt/xdk-ia. The following details the default tool set
Native Location Alternate tool set location
/opt/aCC/bin/aCC /opt/xdk-ia/opt/aCC/bin/aCC /opt/aCC/lbin/ctcom /opt/xdk-ia/opt/aCC/lbin/ctcom /opt/langtools/lbin/ucomp /opt/xdk-ia/opt/langtools/lbin/ucompInvoking the compiler driver 'aCC' results in the invocation of tool set components from the alternate location above.
The TARGETROOT environment variable is used as a prefix for all references
to target set components and must also be set
when using a non-native development kit. Some of the target set
components are header files, archive libraries, and shared libraries.
Example:
If a target tool set is installed in directory /opt/xdk-ia/ then,
export TARGETROOT=/opt/xdk-iaprefixes all references to the target tool set components with /opt/xdk-ia.
Native Location Alternate tool set location
/usr/include /opt/xdk-ia/usr/include /opt/aCC/include* /opt/xdk-ia/opt/aCC/include* /usr/lib /opt/xdk-ia/usr/lib /opt/aCC/lib /opt/xdk-ia/opt/aCC/libEnvironment variables like LPATH and options like -l or -L override $TARGETROOT prefixing.
If the compiler is non-native and installed in a different place, the
directory path can be prefixed for all references to the compiler.
You have to set the environment variables XDKROOT or SDKROOT to point
to that directory.
For example:
If the compiler is installed in directory /user/foo, you can say,
export SDKROOT=/user/fooThis prefixes all references to the compiler with /user/foo.
Default path New path for compiler
/opt/aCC/bin/aCC /user/foo/opt/aCC/bin/aCC /opt/aCC/lbin/ctcom /user/foo/opt/aCC/lbin/ctcom /opt/langtools/lbin/ucomp /user/foo/opt/langtools/lbin/ucompFor information on SDK usage scenarios, please refer to the paper, "HP-UX Software Development Kit User's Guide" on http://www.hp.com/dspp.
The compiler may not be able to recover from all errors and still display:
445 Cannot recover from earlier errorsinstead of
699 Error limit reached: halting compilationExample:
$export aCC_MAXERR=100 $aCC -c buggy.c
For example:
__thread int j = 2; // allowed with this release int main() j = 20; }Since thread private memory is allocated during runtime, virtual addresses of the thread private variables should not be used in situations where compile time evaluation of the addresses is necessary. Following are some of the sample incorrect usages:
Ex. #1:
__thread int tpv_1; __thread int *ptr = &tpv_1; //incorrectEx. #2:
__thread int tpv_1; int *ptr = &tpv_1; //incorrect
In the non -I- case, use of directory prefixes in parent #include directives causes the compiler to look in some directory offset from the directory of the top-level source file. Analogously, in the -I- case, use of directory prefixes in parent include files in effect define an offset relative to the directories on the search list. This is equivalent to explicitly specifying the directory prefix explicitly in the child #include "..." directive. In fact, modifying the source #include directive in this way would allow the intended included file to be found without requiring prefixinclude support in the preprocessor.
Here's an example of the problem:
$ ls a.c incl/ mk
$ ls incl f.h x.h y.h
$ cat a.c #include "incl/f.h"
$ cat incl/f.h #include "incl/y.h" #include "x.h"
$ cat incl/x.h int x;
$ cat incl/y.h int y;
$ aCC -c -I. a.c $ # previous versions of aC++ $ aCC -c -I. -I- -I. a.c "./incl/f.h", line 2: Error: Could not open include file "x.h".Note that a.c compiles fine with "-I." but with "-I. -I- -I." it fails to find x.h in "-I.".
With the prefixinclude feature in effect, the subdirectory prefix (in this case "incl") is inherited from the including file for #include "..." style includes. So, if an including file was included as "prefix/includer" or <prefix/includer> then a file "includee" included by "prefix/includer" is first searched for using "prefix/includee", and if that fails, is next searched for using "includee". Using each of appropriate -I paths.
Searches for #include <...> files are not affected by prefixinclude, only #include "..." file searches have been enhanced.
Required disk space is 12 MB. Memory requirements vary with settings used for performance measurement.
The 2.0 library is not compatible with the version 1.2.1 Standard C++ Library previously bundled with HP aC++. HP aC++ will continue support for standard C++ library 1.2.1 without name or location change. Customers should not notice any change when -AA is not used. However, the 1.2.1 library is deprecated and will be replaced by the new library eventually.
If you wish to use the new 2.0 library, you must use the -AA option
consistently to compile and link all translation units. Mixing object
files within an executable is not supported.
The default is for -AA to be on with -Wc,-ansi_for_scope,off.
The new -AP option turns -AA mode off.
_____________________________________________________________________________________________________
To install your software, run the SD-UX swinstall command. It will invoke a user interface that will lead you through the installation. For more information about installation procedures and related issues, refer to "Managing HP-UX Software with SD-UX" and other README, installation, and upgrade documentation provided or described in your HP-UX 11.x operating system package.
Depending on your environment, you may also need documentation for other parts of your system, such as networking, system security, and windowing.
HP aC++ requires approximately 203 MB for the files in
/opt/aCC
HP ANSI C requires approximately 167 MB for the files in
/opt/ansic & /opt/ansic/legacy_hpc
The other components require approximately:
17 MB for WDB
63 MB for u2comp.
For more precise sizes, use the command:
/usr/sbin/swlist -a size "YourProductNumber"
_____________________________________________________________________________________________________
Documentation for HP aC++ is described in the following sections.
/opt/aCC/newconfig/TechDocs/templates.ps
/opt/aCC/html/C/templates/templates.htm
The reference is provided as HTML formatted files. You can view these
files with an HTML browser by opening the following file: /opt/aCC/html/libstd_v2/stdref/index.htm
Or select from the initial window of the "HP aC++ Online Programmer's Guide."
NOTE: Although the documentation for Appendix A is supplied with aC++, this is an obsolete interface to Tools.h++ that predates the version that is integrated with the STL. (If building from the Rogue Wave source, you must compile with -DRW_NO_STL.) There are 8 templates documented in the main part of the manual as "still supported". This is incorrect. The interfaces for the following 8 templates must be translated to the new interface with two extra template arguments:
RWTPtrHashDictionary
==> RWTPtrHashMap
RWTPtrHashDictionaryIterator ==> RWTPtrHashMapIterator
RWTPtrHashTable
==> RWTPtrHashMultiSet
RWTPtrHashTableIterator
==> RWTPtrHashMultiSetIterator
RWTValHashDictionary
==> RWTValHashMap
RWTValHashDictionaryIterator ==> RWTValHashMapIterator
RWTValHashTable
==> RWTValHashMultiSet
RWTValHashTableIterator ==> RWTValHashMultiSetIterator
Refer to defect CR JAGaa90638.
NOTE: Refer to the "HP aC++ Online Programmer's Guide" Information
Map for how to obtain additional Rogue Wave documentation and information.
The following documentation is available for use with HP aC++. To order printed versions of Hewlett-Packard documents, refer to manuals(5).
This document is available on the HP-UX 11.x CD-ROM and on the World
Wide Web at the following URL: http://docs.hp.com/hpux/dev/index.html
To order a paper copy, contact Hewlett-Packard's Support Materials Organization (SMO) at 1-800-227-8164 and provide the above part number.
Refer to the Homepage for the latest information regarding:
A.05.36 contains two types of incompatibility with A.05.32:
At the HP aC++ A.01.07 release, the runtime libraries were updated to Rogue Wave's Standard Library version 1.2.1 and Tools.h++ version 7.0.6. These new libraries introduced additional data members in some base classes resulting in incompatibility with the previous versions.
For more details, refer to the HP aC++ World Wide Web Homepage at the following URL and choose "Compatibility between Releases:" http://www.hp.com/go/cpp
When compiling the following example in 32-bit mode, the output is 8.
In 64-bit mode, the output is 16.
extern "C" int printf(const char *,...);
class A {
int a;
public:
virtual void foo(); //virtual function foo, part of class A };
void A::foo() {
return;
}
int main() {
printf("%d\n",sizeof(A));
}
Link time compatibility warnings include the following:
#if __cplusplus >= 199707L // HP aC++ Code #endif // __cplusplus >= 199707L
You need to explicitly declare a type or a member function type
using the typename keyword when all of the following are true:
For example, the following code includes the typename keyword to
declare iterator as a type:
#include <list>
template <class Element>
class Foo {
public:
list<Element> e;
typedef typename list<Element>::iterator MyIterator;
};
For more information, refer to the "HP aC++ Transition Guide" at the following World Wide Web URL:_____________________________________________________________________________________________________
http://www.hp.com/go/cpp
See the latest "HP-UX Software Status Bulletin" support document for other known problems.
To verify the product number and version for your HP aC++ compiler, execute the following HP-UX commands:
what /opt/aCC/lbin/ctcom
what /opt/aCC/bin/aCC
When an incompatible intermediate file is detected, the compiler will issue a message and terminate.
If you want to use "multiplies" in your code, to be compatible with the ISO/ANSI C++ standard, use a conditional compilation flag on the aCC command line. For example, for the following program, compile with the command line:
aCC -D__HPACC_USING_MULTIPLIES_IN_FUNCTIONAL test.c
// test.c int times; //user defined variable #include <functional> // multiplies can be used in
int main() {}
// end of test.c
This flag and the following flags are now automatically set with IPF:
numeric_limits<unsigned int>::max();If you must use the macros.h header, try undefining the macros that conflict:
... #include <macros.h> #undef max #undef min ...
Normally, at program termination (exit) or at a call to shl_unload()
or dlclose(), all explicitly loaded libraries are closed automatically
and static destructors are executed at that time.
When an application calls shl_unload() or dlclose() and that causes
libcsup to be unloaded, it fails when it executes static destructors
at program termination. This causes a program abort, since related
code and data of libcsup are no longer present.
See defect JAGaa86491.
Once library-level versioning is used, calls to shl_load() (see
shl_load(3X)) should specify the actual version of the library that is
to be loaded. For example, if libA.so is now a symbolic link to libA.so.1,
then calls to dynamically load this library should specify the latest version
available when the application is compiled, such as:
shl_load("libA.so.1", BIND_DEFERRED, 0);
This will insure that, when the application is migrated to a system that
has a later version of libA available, the actual version desired is the
one that is dynamically loaded.
The compiler supports the built in function, alloca, defined in
the /usr/include/alloca.h header file. The implementation of the
alloca() routine is system dependent, and its use is not encouraged. alloca()
is a memory allocation routine similar to malloc() (see malloc(3C)). The
syntax is:
void *alloca(size_t <size>);alloca() allocates space from the stack of the caller for a block of at least <size> bytes, but does not initialize the space. The space is automatically freed when the calling routine exits.
Note, memory returned by alloca() is not related to memory allocated by other memory allocation functions. Behavior of addresses returned by alloca() as parameters to other memory functions is undefined.
To use this function, you must use the <alloca.h> header file.