There is a new C++ on the support portal. The V10.1-1 GA release will
stay in place. This new release X86VMS-CXX-A1001-240307-1 contains two
important changes plus a handful of bug fixes. This is a FT for a
future V10.1-2 release.

And the portal page says that the package prerequisites is both V9.2-1
and V9.2-2. Can't be both! We require V9.2-1 but suggest V9.2-2 as
there were some exception handling bug fixes in the OS that might impact
some C++ code.

The two changes are:

1) Initial support for listings. The format of the listing is patterned
after the listing you see on Itanium. It isn't exactly the same, but
we're pretty close if you ask me. Along with /LIST, the /SHOW qualifier
is enabled also. Both are updated in the HELP.

We are still missing the piece in the DWARF debug to help the debugger
(and traceback) convert between source line numbers and listing line
numbers. That is "in progress" but we wanted to get this out there now
to get feedback. [Yes, the other compilers have that info in the DWARF.]

And there is still no support for /MACHINE_CODE on any of the compilers.
You still use ANALYZE/OBJECT/DISASSEMBLE to get that output. It isn't
perfect and we're coming up with some approaches to solve it.

2) new() now returns actual 64-bit pointers. As most of you know, the
default pointer-size switched to 64-bit by default on OpenVMS x86. All
the pointers (unless the /POINTER_SIZE switch is used OR the
pointer-size pragmas) are 64-bits. However, what most people didn't
notice was that new() allocated from the 32-bit heap. All those 64-bit
pointers had 0s in the top 32-bits. That was a happy accident that let
sloppy code that stored those addresses into 32-bit ints or 32-bit
fields in descriptors, etc. However, that limited the amount of memory
you could allocate. Why have all those fancy 64-bit pointers if you
can't use lots of memory?

So now new() returns 64-bit addresses from malloc64(). If you use an
explicit /POINTER_SIZE=32 on the command line, new() will revert to
32-bit heap. However, if you take the default or ask for
/POINTER_SIZE=64, you will get 64-bit addresses.

Like Itanium, the current pointer-size setting with the pragmas does not
influence what new() does, only the command line use of /POINTER_SIZE.
We just copied what the Itanium compiler does but looking at it now, I
think we should do more and look at the current setting based on the
pointer-size pragmas. However, that would be incompatible from what
happens on Itanium. However, I think the number of Itanium programs
that asked for /POINTER_SIZE=64 is limited and hopefully they will
understand.