[Info-vax] VSI C/C++ compiler for OpenVMS expired yesterday!

[John Reagan]

On Monday, September 4, 2023 at 4:12:19 PM UTC-4, Single Stage to Orbit wrote:
> On Mon, 2023-09-04 at 12:57 -0700, John Reagan wrote: 
> > On Monday, September 4, 2023 at 8:18:49 AM UTC-4, Simon Clubley 
> > wrote: 
> > > On 2023-09-02, John Reagan <xyzz... at gmail.com> wrote: 
> > > > Again, my apologies for the ancient timebomb (long story) 
> > > > 
> > > It happens :-) however much it would be nice it didn't... :-) 
> > > 
> > > Has anyone checked to make sure there are no timebombs waiting 
> > > to go off in the other products ? 
> >
> > C++ was the first native compiler prior to all of the LMF code (and 
> > PAKs) being in place. 
> > All of the other compilers and LPs rely on the termination date 
> > feature of a PAK.
> That makes complete sense, can't bootstrap without a working toolchain. 
> What did you use as the host to build the toolchains and all the x86_64 
> bits for VMS jut out of interest? Is OpenVMS for x86 now self hosting 
> and can it build itself? 
> -- 
> Tactical Nuclear Kittens

For the Itanium-hosted cross-compilers, I grabbed LLVM 3.4.2 (the last LLVM
release that claims to be buildable with a C++03 compiler) and compiled it
on OpenVMS Itanium.  Our GEM-to-LLVM converter is also written in C++03.

We hooked these pieces to the Itanium frontends for C and BLISS and they just
think they are talking to GEM.  The G2L/LLVM 3.4.2, we then had working cross-compilers
to build the OS and for bootstrap some of the compiler pieces (our frontends are written
either in C and/or BLISS)   The Macro compilers is similar but used a smaller portion of
LLVM and needed other work (think of it as the equivalent of G2L).  And the Macro-32
parser is written in Macro-32.

For native compilers, we initially used those cross-compilers to build x86 versions of the C
and BLISS frontend.  For C++, we had no cross-compiler (clang 3.4.2 wouldn't go thru the
Itanium C++ compiler no matter how hard I pounded on it it).

For the building LLVM (and G2L) that were OpenVMS aware, we first took LLVM/clang 10.0.1
(the current version at the time) and built them on Linux.  We then added some OpenVMS
features and again built those compilers on Linux (call them clang 10.0.1v).  Now use THAT
compiler (Linux-hosted, OpenVMS-target) to build clang 10.0.1v again with more features.  
Move those objects over to an OpenVMS box.  Do the same thing with libcxx.  Link them all 
together.  libcxxabi needs work to layer the code which wants libunwind onto a system with 
the LIB$CALLING standard routines.  Same concepts, different names (and we have some 
of a GPL-free libunwind inside of the LIB$ routines).

We are now using those 1st generation native compilers to build the 2nd generation
native compilers except for C++.  We're still doing the Linux thing for now as the LLVM/clang
build needs things like CMake (which of course is written in C++ and needs to be bootstrapped
with a C++ compiler).  Those 2nd generation compiler builds are done on OpenVMS x86 V9.2-1
systems on a hypervisor.  Testing is also done on virtual machines.

The native compilers have most of the optimization but those 1st generation compilers themselves
are unoptimized (they are built with cross-compilers).  The 2nd generation native compilers are themselves
built with optimization and generate optimized code.

As for the OS itself, the build system is a little more complex (and baroque) and is still being worked on.