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.

Intel and Itanium are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States and other
countries.

UNIX is a registered trademark of The Open Group.

Portions of the ANSI C++ Standard Library have been implemented using
source licensed from and copyrighted by Rogue Wave Software, Inc. All
rights reserved.

Information pertaining to the C++ Standard Library has been edited and
reprinted with permission of Rogue Wave Software, Inc. All rights
reserved.

These release notes describe the new features, differences, and
restrictions of the C++ X7.1 compiler for I64 systems over the
C++ V6.5 compiler for Alpha systems.

This release of the compiler uses a new technology base that differs
substantially from both HP C++ for OpenVMS Alpha and HP C for OpenVMS
I64. Although a great deal of work has been done to make it highly
compatible with HP C++ for OpenVMS Alpha, there are a number of
differences that you will likely notice. Some of these differences are
temporary, some are changes that will be reflected in the next version
of the compiler for Alpha systems, and some are permanent. Among the
permanent differences are:

Resource requirements Programs will usually use more memory
both at compile time and at run time. See Section 2.2.1.

Floating-point behaviors The default is
/FLOAT=IEEE/IEEE_MODE=DENORM_RESULTS. Consistent use of qualifiers
across compilations is required. See Section 2.2.5.

Removal of the CFRONT dialect (which will also be removed in the
next release of the C++ Alpha compiler).

String literal type change. For standards-compliance and link
compatiblity between compiler dialects, ordinary string literals now
have the type "array of const char" in all compiler dialects on I64
systems and on Alpha systems when compiling in /MODEL=ANSI mode.
When compiling in /MODEL=ARM mode on Alpha systems, string literals
are of type "array of char" in all compiler dialects.

This section contains the release notes for the C++ X7.1
compiler for OpenVMS I64 systems. See Section 3 for the release
notes for the standard library, language run-time support library, and
class library.

As required by the C++ standard, the
<cname>
headers define C names in the
std
namespace. In /NOPURE_CNAME mode, the names are also inserted into the
global namespace. See the description of the /[NO]PURE_CNAME compiler
qualifier.

The
<cname>
headers are located in the same TLB library that contains the C++
standard and class library headers: SYS$SHARE:CXXL$ANSI_DEF.TLB.

The /[NO]FIRST_INCLUDE qualifier is added. It has the following format:

/[NO]FIRST_INCLUDE=(file[,...])

This qualifier includes the specified files before any source files. It
corresponds to the Tru64 UNIX-FI
switch.

When /FIRST_INCLUDE=file is specified, file is
included in the source as if the line before the first line of the
source was:

#include "file"

If more than one file is specified, the files are included in their
order of appearance on the command line.

This qualifier is useful if you have command lines to pass to the C
compiler that are exceeding the DCL command-line length limit. Using
the /FIRST_INCLUDE qualifier can help solve this problem by replacing
lengthy /DEFINE and /WARNINGS qualifiers with
#define
and
#pragma message
preprocessor directives placed in a /FIRST_INCLUDE file.

The effect of each
#pragma include_directory
is as if its string argument (including the quotes) were appended to
the list of places to search that is given its initial value by the
/INCLUDE_DIRECTORY qualifier, except that an empty string is not
permitted in the pragma form.

The
#pragma include_directory
directive has the following format:

#pragma include_directory <string-literal>

This pragma is intended to ease DCL command-line length limitations
when porting applications from POSIX-like environments built with
makefiles containing long lists of -I options that specify directories
to search for headers. Just as long lists of macro definitions
specified by the /DEFINE qualifier can be converted to
#define
directives in a source file, long lists of places to search specified
by the /INCLUDE_DIRECTORY qualifier can be converted to
#pragma include_directory
directives in a source file.

Note that the places to search, as described in the help text for the
/INCLUDE_DIRECTORY qualifier, include the use of POSIX-style pathnames,
for example
"/usr/base"
. This form can be very useful when compiling code that contains
POSIX-style relative pathnames in
#include
directives. For example,
#include <subdir/foo.h>
can be combined with a place to search such as
"/usr/base"
to form
"/usr/base/subdir/foo.h"
, which will be translated to the filespec "USR:[BASE.SUBDIR]FOO.H"

This pragma can appear only in the main source file or in the first
file specified on the /FIRST_INCLUDE qualifier. Also, it must appear
before any
#include
directives.

There have been some changes in the /WARNINGS qualifier. These include
bug fixes and improved compatibility with the C compiler. Some changes
that might affect user compilations are:

The /WARNINGS=ENABLE=ALL qualifier now enables all compiler
messages including informational-level messages.

The /WARNINGS=INFORMATIONALS qualifier continues to enable most
informationals, but we recommend that /WARNINGS=ENABLE=ALL be used
instead

Using /WARNINGS=INFORMATIONALS=<tag> no longer enables all
other informational messages.

The move from Alpha systems to I64 systems will cause some minor
differences in certain compiler diagnostics that are signaled from the
code generator. As a result, diagnostics for unreachable code and
fetches of uninitialized variables might be different on the two
platforms. In addition to a change in message text, some conditions
detected on one platform might not be detected on the other.

The C++ compiler for I64 systems is built from a different code base
than the C++ compiler for Alpha systems, and that code base is larger
than the code base for Alpha. Also, I64 images tend to be somewhat
larger than Alpha images in general. Image size mostly affects
working-set size and the amount of pagefile quota needed to execute an
image without exhausting virtual memory. If you find that programs that
compile and run successfully on Alpha run out of memory on I64 systems
(either during compilation or when run), you probably need to increase
your pagefile quota. There are no specific guidelines at this time. You
might start by doubling the quota that was sufficient on Alpha, and
then use a "binary-search" approach to arrive at a better quota value
for I64 systems (doubling again, or halving the increment, until your
biggest programs and compilations have just enough memory, and then
adding an appropriate safety margin).

Some of the compiler dialects (options to the /STANDARD qualifier)
have been updated to reflect the most recent behaviors of the compilers
that the dialect is attempting to match. Other changes involve the
removal of less significant or undesirable compatibility features. If a
dialect has changed in a way that impacts you significantly, report it
as described in Section 6.

The object model and the name mangling scheme used by the C++ compiler
on I64 systems are different from those used on Alpha systems
(different from both /MODEL=ARM and /MODEL=ANSI). The I64 compiler uses
the interface described by the I64 Application Binary Interface (ABI).

The compiler has some additional encoding rules that are applied to
symbol names after the ABI name mangling is determined. All symbols
with C++ linkage have CRC encodings added to the name, are uppercased,
and shorten to 31 characters if necessary. Since the CRC is computed
before the name is uppercased, the symbol name is case sensitive even
though the final name is uppercase. /names=3Das_is and /names=3Dupper
are not applicable to these symbols.

All symbols without C++ linkage will have CRC encodings added if they
are longer then 31 characters and /names=3Dshorten is specified. Global
variables with C++ linkage are treated as if they have non-C++ linkage
for compatibility with C and older compilers.

A number of other qualifiers not supported on I64 systems are, by
default, silently ignored by the compiler. These qualifiers fall into
two groups:

Qualifiers that should not alter the behavior of a correct program
so, if ignored, should have no visible effect. Qualifiers that enable
optimizations typically have this characteristic.

Qualifiers that might affect program behavior but, if ignored,
produce no significant change in the vast majority of programs.
Examples of qualifiers in this category are /NORTTI (the run-time
information is always generated) and /MODEL=ARM (the ANSI model is
functionally superior, and binary compatibility with existing object
code is not an issue for the OpenVMS I64 platform).

Two optional compiler messages can be enabled to diagnose most of these
cases:

The QUALNA message diagnoses uses of the first group.

The QUALCHANGE message diagnoses uses of the second group.

If you encounter porting problems, compile /WARN=ENABLE=QUALCHANGE to
determine if a qualifier change might be affecting your application.

If you wish to clean up your build scripts to remove extraneous
qualifiers that are not meaningful on I64 systems, you can enable the
QUALNA message.

A list of these qualifiers follows:

/ARCHITECTURE=optionAn additional keyword has been
added: ITANIUM2. If an Alpha keyword (EV4, EV5, EV56, PCA56, EV6,
EV68, EV7) is specified for option, it is ignored.

/ASSUME The following /ASSUME options are ignored on I64
systems and should not cause any behavior changes:

/CHECK=UNINITIALIZED_VARIABLES This qualifier has no effect in
this version of the compiler.

/DISTINGUISH_NESTED_ENUMS This qualifier only modified the
behavior of programs compiled with /MODEL=ARM. Since that model is not
supported on the I64 platform, this qualifier is meaningless.

/EXCEPTIONS=NOCLEANUP The NOCLEANUP keyword for the /EXCEPTIONS
qualifier is ignored.

/EXCEPTIONS=IMPLICIT The IMPLICIT keyword for the /EXCEPTIONS
qualifier is ignored.

/FLOAT The default for /FLOAT on OpenVMS I64 systems is
IEEE_FLOAT. See Section 2.2.5 for more information about
floating-point behavior on I64 systems.

/IEEE_MODE The default for /IEEE_MODE on I64 systems is
DENORM_RESULTS, which generates infinities, denorms, and NaNs without
exceptions. On OpenVMS Alpha systems, the default for /IEEE_MODE
when using /FLOAT=IEEE_FLOAT is FAST, which causes a FATAL error for
exceptional conditions such as divide-by-zero and overflow. See
Section 2.2.5 for more information.

/MACHINE_CODE The /MACHINE_CODE qualifier output will appear in
an .S file in the same directory as your listing file.

The /MODEL=ARM qualifier is treated the same as the default
/MODEL=ANSI (except for the optional QUALCHANGE diagnostic).

/OPTIMIZE There are several changes to the /OPTIMIZE qualifier:

On I64 systems, for /OPTIMIZE=INLINE, the keywords AUTOMATIC and
SPEED do the same thing. Also, the ALL keyword does not necessarily
result in every possible call being inlined, as it does on Alpha
systems.

The /OPTIMIZE=TUNE qualifier takes a new keyword: ITANIUM2, which
is the default at this time. If you specify an Alpha keyword, it is
ignored.

The /OPTIMIZE=UNROLL=n qualifier on I64 systems does not
have the ability to control the specific number of times a loop is
unrolled. The only accepted values are /OPTIMIZE=UNROLL=1 which
disables loop unrolling, and /OPTIMIZE=UNROLL=0 which allows the
compiler's optimizer to decide how the loop should be unrolled. The
default is /OPTOMICE=UNROLL=0.

/OPTIMIZE=LIMIT_INLINE is ignored.

/PREFIX_LIBRARY_ENTRIES Note that
/PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES prefixes all functions defined by
the C99 standard including those that may not be supported in the
current run-time library. So calling functions introduced in C99 that
are not yet implemented in the OpenVMS C RTL will produce unresolved
references to symbols prefixed by DECC$ when the program is linked. The
compiler now issues a CC-W-NOTINCRTL message when it prefixes a name
that is not in the current C RTL.

/TEMPLATE See Section 2.2.10 for information on template
instantiation.

/POINTER_SIZE=(SHORT,32) is ignored. Mixed pointer types are not
supported at this time.

/SHOW=STATISTICS The /SHOW=STATISTICS qualifier is ignored at
this time.

/STANDARD=CFRONT The /STANDARD=CFRONT qualifier is no longer
available. If it is specified, the compiler issues a warning message
and uses the default dialect, /STANDARD=ANSI.

The following command-line qualifier is new for C++ X7.1 for
I64 systems:

/[NO]PURE_CNAME Affects insertion of the names into the global
namespace by
<cname>
headers. In /PURE_CNAME mode, the
<cname>
headers insert the names into the
std
namespace only, as defined by the C++ Standard, and the __PURE_CNAME
macro is predefined by the compiler. In /NOPURE_CNAME mode, the
<cname>
headers insert the name into the
std
namespace and also into the global namespace. The default depends
on the standard mode:

In /STANDARD=STRICT_ANSI mode, the default is /PURE_CNAME.

In all other standard modes, the default is /NOPURE_CNAME.

Inclusion of a
<name.h>
header instead of its
<cname.h>
counterpart (for example,
<stdio.h>
instead of
<cstdio>
) results in inserting names defined in the header into both the
std
namespace and the global namespace. Effectively, this is the same as
the inclusion of a
<cname>
header in the /NOPURE_CNAME mode. See Section 2.1.1 for more
information.

On OpenVMS I64 systems, /FLOAT=IEEE_FLOAT is the default floating-point
representation. IEEE format data is assumed and IEEE floating-point
instructions are used. There is no hardware support for floating-point
representations other than IEEE, although you can specify the
/FLOAT=D_FLOAT or /FLOAT=G_FLOAT compiler option.

These VAX floating-point formats are supported in the I64 compiler by
generating run-time code that converts VAX floating-point formats to
IEEE format to perform arithmetic operations, and then converts the
IEEE result back to the appropriate VAX floating-point format. This
imposes additional run-time overhead and some loss of accuracy compared
to performing the operations in hardware on Alpha and VAX systems. The
software support for the VAX formats is provided to meet an important
functional compatibility requirement for certain applications that need
to deal with on-disk binary floating-point data.

On I64 systems, the default for /IEEE_MODE is DENORM_RESULTS, which is
a change from the default of /IEEE_MODE=FAST on Alpha systems. This
means that by default, floating-point operations may silently generate
values that print as Infinity or Nan (the industry-standard behavior),
instead of issuing a fatal run-time error as they would when using VAX
floating-point format or /IEEE_MODE=FAST. Also, the smallest-magnitude
nonzero value in this mode is much smaller because results are allowed
to enter the denormal range instead of being flushed to zero as soon as
the value is too small to represent with normalization.

The conversion between VAX floating-point formats and IEEE formats on
the Intel Itanium architecture is a transparent process that will not
impact most applications. All you need to do is recompile your
application. Because IEEE floating-point format is the default, unless
your build explicitly specifies VAX floating-point format options, a
simple rebuild for I64 systems will use the native IEEE formats
directly. For the large class of programs that do not directly depend
on the VAX formats for correct operation, this is the most desirable
way to build for I64 systems.

When you compile an OpenVMS application that specifies an option to use
VAX floating-point on an I64 system, the compiler automatically
generates code for converting floating-point formats. Whenever the
application performs a sequence of arithmetic operations, this code
does the following:

Converts VAX floating-point formats to either IEEE single or IEEE
double floating-point formats.

Performs arithmetic operations in IEEE floating-point arithmetic.

Converts the resulting data from IEEE formats back to VAX formats.

Where no arithmetic operations are performed (VAX float fetches
followed by stores), no conversion will occur. The code handles such
situations as moves.

VAX floating-point formats have the same number of bits and precision
as their equivalent IEEE floating-point formats. For most applications,
the conversion process will be transparent and, therefore, a non-issue.

In a few cases, arithmetic calculations might have different results
because of the following differences between VAX and IEEE formats:

Values of numbers represented

Rounding rules

Exception behavior

These differences might cause problems for applications that do any of
the following:

Depend on exception behavior

Measure the limits of floating-point behaviors

Implement algorithms at maximal processor-specific accuracy

Perform low-level emulations of other floating-point processors

Use direct equality comparisons between floating-point values,
instead of appropriately ranged comparisons (a practice that is
extremely vulnerable to changes in compiler version or compiler
options, as well as architecture)

You can test an application's behavior with IEEE floating-point values
by first compiling it on an OpenVMS Alpha system using
/FLOAT=IEEE_FLOAT/IEEE_MODE=DENORM.

If that produces acceptable results, then simply build the application
on the OpenVMS I64 system using the same qualifier.

If you determine that simply recompiling with an /IEEE_MODE qualifier
is not sufficient because your application depends on the binary
representation of floating-point values, then first try building for
your I64 system by specifying the VAX floating-point option that was in
effect for your VAX or Alpha build. This causes the representation seen
by your code and on disk to remain unchanged, with some additional
runtime cost for the conversions generated by the compiler. If this is
not an efficient approach for your application, you can convert VAX
floating-point binary data in disk files to IEEE floating-point formats
before moving the application to an I64 system.

/IEEE_MODE Notes

On Alpha systems, the /IEEE_MODE qualifier generally has its greatest
effect on the generated code of a compilation. When calls are made
between functions compiled with different /IEEE_MODE qualifiers, each
function produces the /IEEE_MODE behavior with which it was compiled.

On I64 systems, the /IEEE_MODE qualifier primarily affects only the
setting of a hardware register at program startup. In general, the
/IEEE_MODE behavior for a given function is controlled by the
/IEEE_MODE option specified on the compilation that produced the main
program: the startup code for the main program sets the hardware
register according the command-line qualifiers used to compile the main
program.

When applied to a compilation that does not contain a main program, the
/IEEE_MODE qualifier does have some effect: it might affect the
evaluation of floating-point constant expressions, and it is used to
set the EXCEPTION_MODE used by the math library for calls from that
compilation. But the qualifier has no effect on the exceptional
behavior of floating-point calculations generated as inline code for
that compilation. Therefore, if floating-point exceptional behavior is
important to an application, all of its compilations, including the one
containing the main program, should be compiled with the same
/IEEE_MODE setting.

Even on Alpha systems, the particular setting of
/IEEE_MODE=UNDERFLOW_TO_ZERO has the following characteristic: its
primary effect requires the setting of a runtime status register, and
so it needs to be specified on the compilation containing the main
program in order to be effective in other compilations.

More Information

For more information on I64 floating-point behavior, see the white paper OpenVMS floating-point arithmetic on the Intel Itanium architecture at a class="udrline" href="http://www.hp.com/products1/evolution/alpha_retaintrust/download/i64-floatin
http://www.hp.com/products1/evolution/alpha_retaintrust/download/i64-floating-pt-wp.pdf
.

The C++ built-in functions available on OpenVMS Alpha systems are also
available on I64 systems, with some differences, as described in this
section. This section also describes built-in functions that are
specific to I64 systems.

The
<builtins.h>
header file contains comments noting which built-in functions are not
available or are not the preferred form for I64 systems. The compiler
issues diagnostics where using a different built-in function for I64
systems would be preferable.

Note

The comments in
<builtins.h>
reflect only what is explicitly present in that header file itself, and
in the compiler implementation. You should also consult the content and
comments in
<pal_builtins.h>
to determine more accurately what functionality is effectively provided
by including
<builtins.h>
. For example, if a program explicitly declares one of the Alpha
built-in functions and invokes it without having included
<builtins.h>
, the compiler might issue the BIFNOTAVAIL error message, regardless of
whether or not the function is available through a system service. If
the compilation does include
<builtins.h>
, and BIFNOTAVAIL is issued, then either there is no support at all for
the built-in function or a new version of
<pal_builtins.h>
is needed.

Here is a summary of these differences on I64 systems:

There is no support for the
asm
,
fasm
, and
dasm
intrinsics (declared in the
<c_asm.h>
header file).

The functionality provided by the special-case treatment of R26 in
an Alpha system
asm
, as in
asm("MOV R26,R0")
, is provided by a new built-in function for I64 systems:

__int64 __RETURN_ADDRESS(void);

This built-in function produces the address to which the function
containing the built-in call will return (the value of R26 on entry to
the function on Alpha systems; the value of B0 on entry to the function
on I64 systems). This built-in function cannot be used within a
function specified to use nonstandard linkage.

The only PAL function calls implemented as built-in functions
within the compiler are the 24 queue-manipulation builtins. The queue
manipulation builtins generate calls to new OpenVMS system services
SYS$<name>, where <name> is the name of the builtin with
the leading underscores removed. Any other OpenVMS PAL calls are
supported through macros defined in the
<pal_builtins.h>
header file included in the
<builtins.h>
header file. Typically, the macros in
<pal_builtins.h>
transform an invocation of an Alpha system builtin into a call to a
system service that performs the equivalent function on an I64 system.
Two notable exceptions are __PAL_GENTRAP and __PAL_BUGCHK, which
instead invoke the I64 specific compiler builtin __break2.

There is no support for the various floating-point built-in
functions used by the OpenVMS math library (for example, operations
with chopped rounding and conversions).

Most built-in functions that take a retry count are not supported.
This is necessary because the retry behavior allowed by Alpha
load-locked/store-conditional sequences does not exist on I64 systems.
There are two exceptions to this: __LOCK_LONG_RETRY and
__ACQUIRE_SEM_LONG_RETRY; in these cases, the retry behavior involves
comparisons of data values, not just load-locked/store-conditional.

The __CMP_STORE_LONG and __CMP_STORE_QUAD built-in functions are
not supported. Use the new __CMP_SWAP form instead.

The
<builtins.h>
header file contains a section at the top conditionalized to just
__ia64 with the support for built-in functions specific to I64 systems.
This includes macro definitions for all of the registers that can be
specified to the __getReg, __setReg, __getIndReg, and __setIndReg
built-in functions. Parameters that are
const
-qualified require an argument that is a compile-time constant.

The following lists the C++ built-in functions available on OpenVMS I64
systems.

HP C++ for OpenVMS I64 optimizes the use of standard C library functions
memcpy
and
memmove
somewhat differently than HP C for OpenVMS I64 and the HP C and C++
compilers for OpenVMS Alpha. Because of this, the use of
memcpy
with arguments that overlap in memory can produce results that differ
from the other compilers.

Note that the behavior of
memcpy
is formally undefined if its arguments overlap; only
memmove
should be used in this case. However, the other compilers generally
treat
memcpy
in a way that handles overlapping arguments in the same way as
memmove
, while HP C++ for OpenVMS I64 does not. So when using
memcpy
, take care that the arguments do not refer to memory that might
overlap; if overlap is a possibility, you must use
memmove
instead of
memcpy
.

On OpenVMS I64 systems, the compiler generates ELF objects. ELF is an
industry standard object format used on many UNIX platforms, including
Linux. This change should be transparent to most users; it is primarily
of interest to compiler and tools developers. The greatest benefit of
this change is that it should make it easier to create development
tools that work on OpenVMS and other platforms.

Extensions to ELF have been used as needed to provide functionality unique to OpenVMS. See the a class="udrline" href="/doc/v81final/pdf/OVMS_v81_port_gd.PDF"
Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers
for more information on ELF.

COMDATS/Group Sections

One feature that ELF provides that is new to OpenVMS is the COMDAT
section group---a group of sections in an object file that can be
duplicated in one or more other object files. The linker is expected to
keep one group and ignore all others. The benefit of this feature is
that it permits compilers to generate definitions for symbols for
things used in multiple objects without having to worry about creating
a single definition in one place. The most notable uses for this
feature are templates and inline functions.

New ELF Type for Weak Symbols

A new Executable and Linkable Format (ELF) type was generated to
distinguish between the two types of weak symbol definitions.

For modules with ABI versions equal to 2 (the most common version used
by compilers):

The Alpha C++ compiler had numerous models for instantiating templates.
Each attempted to solve the issue of how to generate one and only one
copy of each template. The use of ELF on OpenVMS I64 systems provided
the compiler with the additional option of using COMDAT section groups.
Since this technique is superior to all the models supported on Alpha,
this is the only model supported on I64 systems.

In this model, templates are instantiated in a COMDAT section group
inside every object module that uses them. This is very similar to the
/TEMPLATE=LOCAL on Alpha systems, except that when the objects are
linked together, the linker removes the duplicate copies. The primary
advantage of this technique over /TEMPLATE=LOCAL and
/TEMPLATE=IMPLICIT_LOCAL is the reduction in image size.

A secondary advantage is the elimination of distinct data for each
template. For example, if a template maintained a list of elements it
created, each module would have a separate copy of the list. This
behavior does not conform to the standard. If you are currently using
/TEMPLATE=LOCAL or /TEMPLATE=IMPLICIT_LOCAL, you will likely experience
no difficulty from this change.

Not in Repository

The most visible difference that results from this new instantiation
model occurs in models that instantiate templates into the repository
(/TEMPLATE=AUTOMATIC|ALL_REPOSITORY|USED_REPOSITORY).

With the new model, no repository is needed. Build procedures that use
CXXLINK will work transparently. Builds that attempt to manipulate
objects in the repository will fail and will need to be changed. In
most cases, the reason for manipulating the repository directly has
been eliminated with the new template instantiation model.

According to the C++ Standard, an implementation may or may not unwind
the stack before calling terminate when no matching handler is found
for a thrown exception. On I64 systems, the implementation unwinds the
stack. On Alpha systems, it does not.

Full support for allowing a user to override operators
new
and
delete
is not yet completed. As a result, when you override
new
and
delete
, you might see multiply-defined symbols when linking. This will be
fixed in a future release.

By default the compiler's optimizer will not unroll loops. If you wish
to turn the optimization on, you must compile /OPTIMIZE=UNROLL=N

Destruction of Initialized Aggregate Members

If an aggregate class/struct (such as struct B in the example below)
contains a member with a destructor, and an object of that class is
initialized with a brace-enclosed initializer list, and initialization
of some member terminates by throwing an exception (thereby
interrupting the initialization of the B object), members already
completely initialized at that point will not be destructed. However,
if the B object is completely initialized, each of its members will be
destructed correctly.

Optimized debugging is not supported in HP C++ X7.1 for
OpenVMS I64 systems.

Examining floating point values when compiling
/FLOAT=(D_FLOAT,G_FLOAT) On OpenVMS I64 systems, the default
floating point type is IEEE. If you compile your program with any of
these qualifiers: /G_FLOAT, /FLOAT=(D_FLOAT) or /FLOAT=(G_FLOAT) your
floating point numbers will be represented internally as integers.
Therefore to examine them as floating point values, you must specify
the appropriate data type (EXAMINE/D_FLOAT, EXAMINE/G_FLOAT or
EXAMINE/F_FLOAT) when using the EXAMINE command in the OpenVMS I64
debugger.

Inherited Data Members You cannot specify multiple base names.
For example, in the program below, to examine member f_member, we can
say: "examine j_object.f_member" or "examine j_object.I::f_member" but
we cannot say "j_object.I::G::f_member".

DBG> exam j_object.B::A::a_member
%DEBUG-W-NOFIELD, 'B::A::a_member' is not a field in this record
DBG> deposit j_object.I::a_member = 13

Breakpoints on opening and closing braces of a function The
OpenVMS I64 debugger may give unexpected results when examining values
at the final brace (}) of a routine. On OpenVMS I64 systems, a
workaround to set a break on the last source line of a routine. This is
because destructors for the routine may run after the final source line
and before the final (}).

Overloaded Functions If you attempt to set a break on an
overloaded function without providing the argument list, debug may
display the %DEBUG-E-NOSYMBOL message instead of displaying the
overload list. To see the list of overloaded functions use the sho
symbol command. Currently there is a problem with setting
breakpoints on an operator. By using the %name feature of debug, it
should be possible to set a breakpoint on an a user defined operator,
just as one can set a breakpoint on a user defined destructor. However,
this feature is not working at the present time. Please workaround this
problem by setting a breakpoint on the appropriate line number.

// using %name you can set a break on a destructor
DBG> set break stack::%name'~stack'
// however setting a break on an operator is not working yet
DBG> set break stack::%name'operator++'()
%DEBUG-I-NOTUNQOVR, symbol 'stack::operator++' is overloaded overloaded name stack::operator++
instance stack::operator++(int)
instance stack::operator++()
%DEBUG-E-REENTER, reenter the command using a more precise pathname

Pointer to member On OpenVMS I64 systems, the compiler is not
yet emitting full debug information for pointers to members.

Limited support for namespaces On OpenVMS I64 systems, the
compiler is not yet emitting full debug information for namespaces.

Unused type and unused labels On OpenVMS I64 systems, the
/debug qualifier means /DEBUG=(TRACEBACK,BRIEF) which causes the
compiler to omit debug information for unused labels and unused types,
even when /NOOPTIMIZE is specified. This feature results in much
smaller object files. If unused labels and unused types are desired,
please specify the SYMBOLS keyword explicitly (/DEBUG=(SYMBOLS).

source line numbers and listing line numbers on OpenVMS Alpha
systems, the debugger will display listing line numbers. However, the
HP C++ X7.1 compiler on OpenVMS I64 systems does not yet
support debugging with listing line numbers. Instead you will see
source line numbers when in the debugger. For Example: in the
following program which contains two include files, on OpenVMS Alpha
the debugger displays the same listing line numbers as in the listing
file. However on OpenVMS I64, the generic DWARF 3 filename and line
number system is used in the debugger, while a listing file will
contain standard VMS style listing line numbers.

Breakpoints on
for
loops On OpenVMS Alpha systems, if you set a breakpoint on a
for
loop that resides on a single source line, the debugger triggers only
once; the
for
loop is considered a single statement. On OpenVMS I64 systems, the
same situation causes the debugger to trigger on each iteration of the
for
loop. Consider the following
for
statements:

On OpenVMS Alpha systems, the debugger treats the first two example
loops above as single statements, even with delimiting braces. But if
the loop is spread over several source lines, as in the third example,
the OpenVMS Alpha debugger treats it as a loop. On OpenVMS I64
systems, all three of the above
for
statements are treated as loops.

For I64 systems, the C++ standard library has been upgraded and
organized as a shareable image. All applicable fixes and enhancements
done in the C++ standard library for Alpha systems, have been applied
to the C++ standard library for I64 systems.

For I64 systems, the C++ class library is based on the same code as the
C++ class library on Alpha systems. The major change in the C++ class
library for I64 systems is the removal of the tasks and complex
packages.

On Alpha systems, the C++ standard library and language run-time
support library is delivered in an object library, LIBCXXSTD.OLB,
shipped with the compiler kit.

On I64 systems, the C++ standard library and language run-time support
library are delivered as separate system shareable images shipped with
the base operating system. The names of the images are: CXXL$RWRTL.EXE
and CXXL$LANGRTL.EXE, respectively. The images reside in the
SYS$LIBRARY directory and are installed at system startup. The
LIBCXXSTD.OLB object library does not exist on I64 systems.

The language run-time support library no longer validates if a
negative value has been specified in a call to operator
new
. Instead, the value is treated as an unsigned value, and an attempt is
made to dynamically allocate the specified memory.

There are two major changes in the C++ standard library for I64 systems
as compared with the standard library for Alpha systems:

The C++ standard library has been upgraded from Version 2.0 of the
Rogue Wave C++ Standard Library to Version 3.0.

The C++ standard library is delivered with the operating system as
the installed system shareable image SYS$SHARE:CXXL$RWRTL.EXE, and also
in STARLET.OLB in the object form for linking /NOSYSSHARE. On I64
systems, there is no LIBCXXSTD.OLB, which is the object library where
the C++ standard library for OpenVMS Alpha resides.

Additional standard library changes, known issues, and platform
differences are noted in the following sections.

While from the customers' perspective the change in the library
distribution model is supposed to be transparent (except that
application images will be much smaller on I64 systems), users on I64
systems may find that the new C++ Standard Library is much less
forgiving in terms of including all necessary library headers than the
old Standard Library.

For example, the following program compiles cleanly on OpenVMS Alpha
systems despite the fact that it does not include the <iostream>
header necessary for the
std::cout
object:

However, on OpenVMS I64 systems, compilation fails with the following
error:

%CXX-E-UNDECLARED, identifier "cout" is undefined

It is nearly impossible to describe all combinations of library
constructs and header files that would compile cleanly on Alpha systems
and yet fail to compile on I64 systems because a library header
required by the C++ standard for a particular construct has not been
included. If a program that used to compile cleanly on an Alpha system
fails to compile on an I64 system, it is always a good idea to check
that all necessary library headers are included.

A program that includes internal RW stdlib V2.0 library headers, like
<stddefs>
or
<stdcomp>
, or that uses internal library macros _RW_*, will have to be modified
because the new C++ standard library does not necessarily have the same
internal headers or use the same internal macros as the old one.

This initialization is not required by the C++ standard, and on I64
systems the C++ standard library does not do it.

On I64 systems, map and multimap containers require the
standard-conformant form of allocator class: allocator<pair<const
Key, T> >. For example, on Alpha systems, it is possible to
declare an object of class multimap as the following, with the second
template argument of allocator class omitted:

On I64 systems, iostreams extraction operators truncate
out-of-range integer values to the maximum possible value for a given
type, and set the failbit for the stream. For example, consider the
following program:

Note that on I64 systems, the failbit for the stream is set.
According to the C++ Standard, Section 22.2.2.1 - Template class
num_get [lib.locale.num.get], an input that would have caused
scanf
to report an input failure should result in setting ios_base::failbit
to err. Since on OpenVMS,
scanf
reports an input failure in this case (this is an undefined behavior
from the point of view of the C standard), the behavior of the C++
standard library on I64 systems is standard-compliant.

On Alpha systems, the find template function is implemented using
operator!=
. On I64 systems, this function is implemented using
operator==
, which according to the C++ standard is the operator the
find
function should be using. Consequently, if no conversion from
*InputIterator
to
T
exists, on Alpha systems the following function can be instantiated
only if
operator!=(*InputIterator,T)
exists:

find(InputIterator first, InputIterator last, const T& value)

On I64 systems, however, the function can be instantiated only if
operator==(*InputIterator,T)
exists. The following program illustrates the difference. If you
comment out the line
bool operator!=(S, int);
, the program does not compile on Alpha systems. If you comment out the
line
bool operator==(S, int);
, the program does not compile on I64 systems. The behavior on I64
systems is the standard-conformant behavior.

On I64 systems, an attempt to write into a stream opened for read
(ios::in), causes the stream badbit bit to be set. On both Alpha
and IPF systems, nothing is written into a stream opened for read.
However, on Alpha systems, the stream badbit bit is not set. The
C++ standard does not provide explicit guidance about what to do in
this case. However, the behavior on I64 systems is more reasonable---at
least there is an indication that something was wrong.

On I64 systems, reverse_iterator cannot be instantiated on
vector<bool>::iterator type. For example, the following
program, which compiles cleanly on Alpha systems, does not compile on
I64 systems:

On I64 systems, for a random access iterator, operator-(const
random_access_iterator&) returning
difference_type
must be
const
. For example, the following program compiles cleanly on Alpha
systems. However, on I64 systems it compiles only if
// const
is uncommented.

Table 76 in the C++ standard specifies the requirements for a
random access iterator. It says the expression
b - a
must be valid, where
a
and
b
denote values of X, the random access iterator. It is not completely
clear from the standard whether values of X also imply
const
values of X, but if the answer is yes, the behavior on I64 systems is
correct.

On I64 systems, an attempt to call the strstream.seekg(0) function
for an empty stream (the one whose 'next' pointer is NULL) causes the
stream failbit to be set. This is a standard-compliant behavior.
Notice that after the failbit is set for the stream, the
strstream.str() function returns a NULL pointer.

On I64 systems, after a call to string.resize(newsize),
string.capacity() does not necessarily returns newsize. While on
Alpha systems the string.capacity() function returns newsize, this is
not required by the C++ standard. A program relying on Alpha behavior
should be modified to call the string.size() function instead.

On I64 systems, there is no overload of basic_string class for type
bool
. Version v3.0 of the Rogue Wave C++ standard library does not have
this problematic nonstandard overload. For OpenVMS Alpha, it has been
recently removed from the library.

On I64 systems, class std::fpos<std::mbstate_t> does not have
the nonstandard member function offset(). You can use fpos::operator
streamoff() instead. For example:

On OpenVMS Alpha systems, operator< used by the non-predicate
forms of the sorting algorithms like push_heap() may or may not be
declared constant. On IPF systems, this operator must be a constant
operator. For example, on OpenVMS Alpha systems, the following program
would compile without 'bool operator<(const S&)' qualified as
const
. On IPF, the
const
is necessary.

The C++ standard does not specify whether or not this program
compiles. Since operator< must induce a strict-weak ordering on its
arguments, which prevents it from modifying their values, there should
be no reason not to declare it
const
.

Because of changes in the architecture on I64 systems, CXXLINK plays a
much smaller role. Its only remaining purpose is to provide human
readable (demangled) names for mangled C++ names in diagnostics
generated by the linker.

Specific changes are:

There is no LIBCXXSTD.OLB On I64 systems, there is no
LIBCXXSTD.OLB, which is the object library where the C++ standard
library for OpenVMS Alpha resides. See Section 3.4 for more
information.

The library is reorganized The C++ libraries have been
reorganized and incorporated into the base system. CXXLINK no longer
needs to specify any C++ libraries when invoking the system linker. See
Section 3 for more information.

There are no templates in a repository With the new template
instantiation model, objects are no longer placed in a repository.
Therefore, CXXLINK no longer needs to look at the repositories for
templates. See Section 2.2.10 for more information.

To install HP C++ X7.1 for OpenVMS I64 systems, set the default
directory to a writeable directory to allow the IVP to succeed. Then
run the PRODUCT INSTALL command, pointing to the kit location. For
example:

$ PRODUCT INSTALL CXX/SOURCE=NODE1$::DEV1$:[I64_CPP_KIT]
The following product has been selected:
HP I64VMS CXX V7.1-155 Layered Product
Do you want to continue? [YES]
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
HP I64VMS CXX V7.1-155: HP C++ for OpenVMS Industry Standard
Copyright 2004 Hewlett-Packard Development Company, L.P.
This software product is sold by Hewlett-Packard Company
PAKs used: DECCXX or DECCXX-USER
Do you want the defaults for all options? [YES]
Copyright 2004 Hewlett-Packard Development Company, L.P.
HP, the HP logo, Alpha and OpenVMS are trademarks of
Hewlett-Packard Development Company, L.P. in the U.S. and/or
other countries.
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.
Do you want to review the options? [NO]
Execution phase starting ...
The following product will be installed to destination:
HP I64VMS CXX V7.1-155 DISK$ICXXSYS:[VMS$COMMON.]
The following product will be removed from destination:
HP I64VMS CXX V7.1-152 DISK$ICXXSYS:[VMS$COMMON.]
Portion done: 0%...60%...70%...80%...90%...100%
The following product has been installed:
HP I64VMS CXX V7.1-155 Layered Product
The following product has been removed:
HP I64VMS CXX V7.1-152 Layered Product
%PCSI-I-IVPEXECUTE, executing test procedure for HP I64VMS CXX V7.1-155 ...
%PCSI-I-IVPSUCCESS, test procedure completed successfully
HP I64VMS CXX V7.1-155: HP C++ for OpenVMS Industry Standard
The release notes are located in the file SYS$HELP:CXX.RELEASE_NOTES
for the text form and SYS$HELP:CXX_RELEASE_NOTES.PS for the postscript form.