Received this a few mins ago in my mailbox. Seems their C++ compiler
expired yesterday. Oops!

"VMS Software announces availability of the hotfix for the VSI C++
compiler. This update removes the time bomb implemented in previous
releases that rendered the compiler impossible to run after August,
31st 2023 resulting in the following error message:
$ CXX/VERSION
This compiler has expired. Please contact VSI.
%SYSTEM-F-IVEXPDAT, invalid file expiration date
when the C++ compiler for x86 is run. To fix this error, download field
test version A10.0-230901 from the VSI Service Portal and install it on
your system."
"We apologize for the inconvenience."
"Along with the error described above, this kit also fixes a number of
issues found since the field release of A10.0-230731. It can only be
installed on OpenVMS V9.2-1."
--
Tactical Nuclear Kittens

On 9/1/2023 2:54 PM, Single Stage to Orbit wrote:
> Received this a few mins ago in my mailbox. Seems their C++ compiler
> expired yesterday. Oops!
>
> "VMS Software announces availability of the hotfix for the VSI C++
> compiler. This update removes the time bomb implemented in previous
> releases that rendered the compiler impossible to run after August,
> 31st 2023 resulting in the following error message:
> $ CXX/VERSION
> This compiler has expired. Please contact VSI.
> %SYSTEM-F-IVEXPDAT, invalid file expiration date
> when the C++ compiler for x86 is run. To fix this error, download field
> test version A10.0-230901 from the VSI Service Portal and install it on
> your system."
>
> "We apologize for the inconvenience."
>
> "Along with the error described above, this kit also fixes a number of
> issues found since the field release of A10.0-230731. It can only be
> installed on OpenVMS V9.2-1."

A new version has been posted to the SP. I have not yet install nor tested it but I imagine it's been fixed.

John Reagan posted on the VSI portal as well: https://forum.vmssoftware.com/viewtopic.php?p=19506

John H. Reinhardt

On Sat, 2023-09-02 at 02:00 -0500, John H Reinhardt wrote:
> > "Along with the error described above, this kit also fixes a number
> > of
> > issues found since the field release of A10.0-230731. It can only
> > be
> > installed on OpenVMS V9.2-1."
>
>
> A new version has been posted to the SP.  I have not yet install nor
> tested it but I imagine it's been fixed.
>
> John Reagan posted on the VSI portal as well:
> https://forum.vmssoftware.com/viewtopic.php?p=19506

I have today tried to apply the VSI-X86VMS-CXX-A1000-230901-1.ZIP, but
now it is saying it needs to uninstall the VSI X86VMS VMS921X_UPDATE
V1.0 before it can install the compiler!

Performing product kit validation of signed kits ...
%PCSI-I-VSIVALPASSED, validation of KAKAPO$DKA0:[SYS0.][INSTALLERS]VSI-
X86VMS-CX
X-A1000-230901-1.PCSI$COMPRESSED;1 succeeded
The following product has been selected:
VSI X86VMS CXX A10.0-230901 Layered Product
Do you want to continue? [YES]
Information has been saved to allow you to uninstall the following
patches:
RECOVERY DATA SET 001 created 25-AUG-2023 22:02:44.12
-------------------------------------- -----------------------------
---------
PATCH APPLIED TO
-------------------------------------- -----------------------------
---------
VSI X86VMS VMS921X_UPDATE V1.0 VSI X86VMS VMS V9.2-1
-------------------------------------- -----------------------------
---------
* The operation you are performing will invalidate all saved recovery
data sets.
* Recovery data sets represent restore points that have a limited
lifespan. Any
* operation that modifies the product database, except for installation
of other
* patches where recovery data is also saved, makes existing data sets
outdated.
* If you continue, recovery data for the patches listed above will be
deleted.
* The deletion of recovery data does not affect the installation status
of
* patches applied to products that are not participating in this
operation.
* However, continuing with this operation will prevent you from
uninstalling
* these patches at a future time by use of the PRODUCT UNDO PATCH
command.
Do you want to continue? [NO] NO
%PCSIUI-I-USERABORT, operation terminated by user request

Huh?
--
Tactical Nuclear Kittens

On 9/2/23 3:38 AM, Single Stage to Orbit wrote:
> On Sat, 2023-09-02 at 02:00 -0500, John H Reinhardt wrote:
>>> "Along with the error described above, this kit also fixes a number
>>> of
>>> issues found since the field release of A10.0-230731. It can only
>>> be
>>> installed on OpenVMS V9.2-1."
>>
>>
>> A new version has been posted to the SP.  I have not yet install nor
>> tested it but I imagine it's been fixed.
>>
>> John Reagan posted on the VSI portal as well:
>> https://forum.vmssoftware.com/viewtopic.php?p=19506
>
> I have today tried to apply the VSI-X86VMS-CXX-A1000-230901-1.ZIP, but
> now it is saying it needs to uninstall the VSI X86VMS VMS921X_UPDATE
> V1.0 before it can install the compiler!

No, that's not what it's saying. You will not be backing out the V1.0
update; you will be removing the recovery data set that would have
allowed you to back out the update had you encountered problems with it.
It's a normal if eccentric part of applying patches on VMS that the
recovery capability is a fleeting one that disappears with application
of the next patch.

On Sat, 2023-09-02 at 07:18 -0500, Craig A. Berry wrote:
> > I have today tried to apply the VSI-X86VMS-CXX-A1000-230901-1.ZIP,
> > but
> > now it is saying it needs to uninstall the VSI X86VMS
> > VMS921X_UPDATE
> > V1.0 before it can install the compiler!
>
> No, that's not what it's saying.  You will not be backing out the
> V1.0
> update; you will be removing the recovery data set that would have
> allowed you to back out the update had you encountered problems with
> it. It's a normal if eccentric part of applying patches on VMS that
> the recovery capability is a fleeting one that disappears with
> application of the next patch.

Is that what it meant? Jolly good, I'll upgrade the compiler later
today.

Thanks!
--
Tactical Nuclear Kittens

On Saturday, September 2, 2023 at 9:01:14 AM UTC-4, Single Stage to Orbit wrote:
> On Sat, 2023-09-02 at 07:18 -0500, Craig A. Berry wrote:
> > > I have today tried to apply the VSI-X86VMS-CXX-A1000-230901-1.ZIP,
> > > but
> > > now it is saying it needs to uninstall the VSI X86VMS
> > > VMS921X_UPDATE
> > > V1.0 before it can install the compiler!
> >
> > No, that's not what it's saying. You will not be backing out the
> > V1.0
> > update; you will be removing the recovery data set that would have
> > allowed you to back out the update had you encountered problems with
> > it. It's a normal if eccentric part of applying patches on VMS that
> > the recovery capability is a fleeting one that disappears with
> > application of the next patch.
> Is that what it meant? Jolly good, I'll upgrade the compiler later
> today.
>
> Thanks!
> --
> Tactical Nuclear Kittens
Again, my apologies for the ancient timebomb (long story)

And yes, this is just a case of PCSI saying if you install anything after that update, you
can't go back. I don't like that either.

Install the new compiler. You get a few bug fixes and support for include prologue/epilogue files too

On Sat, 2023-09-02 at 12:23 -0700, John Reagan wrote:
> > Is that what it meant? Jolly good, I'll upgrade the compiler later
> > today.
> >
> > Tactical Nuclear Kittens
> Again, my apologies for the ancient timebomb (long story)
>
> And yes, this is just a case of PCSI saying if you install anything
> after that update, you
> can't go back.  I don't like that either. 
>
> Install the new compiler.  You get a few bug fixes and support for
> include prologue/epilogue files too

Yep, looks good!
--
Tactical Nuclear Kittens

On 2023-09-02, John Reagan <xyzzy1959@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 ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, September 4, 2023 at 8:18:49 AM UTC-4, Simon Clubley wrote:
> On 2023-09-02, John Reagan <xyzz...@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 ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
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.

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...@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

On 9/4/23 3:11 PM, 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...@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.

But C++ is not part of the toolchain, at least not that I've ever heard
of. And I doubt if much of the C code in VMS would compile with clang
without modifications.

> What did you use as the host to build the toolchains and all the x86_64
> bits for VMS jut out of interest?

John is the expert, but anyone following the roadmaps over the last
several years knows that C++ is clang++ and the other compilers use a
GEM compatibility layer to generate LLVM IR. And MACRO is special.

> Is OpenVMS for x86 now self hosting
> and can it build itself?

Most of the compilers started out as cross compilers running on Itanium
and as far as anything I've heard that's still what's in use for
building the OS itself. All of the native compilers that are available
are still in field test and likely to prioritize building customer code
for now.

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...@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.

On 9/4/2023 5:19 PM, Craig A. Berry wrote:
> On 9/4/23 3:11 PM, Single Stage to Orbit wrote:
>> On Mon, 2023-09-04 at 12:57 -0700, John Reagan wrote:
>>> 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.
>
> But C++ is not part of the toolchain, at least not that I've ever heard
> of.  And I doubt if much of the C code in VMS would compile with clang
> without modifications.

LLVM is C++ so on x86-64 I would consider C++ part of the VMS toolchain
(strictly speaking toolchain to build toolchain, but ...).

>> Is OpenVMS for x86 now self hosting
>> and can it build itself?
>
> Most of the compilers started out as cross compilers running on Itanium
> and as far as anything I've heard that's still what's in use for
> building the OS itself. All of the native compilers that are available
> are still in field test and likely to prioritize building customer code
> for now.

That is the word.

I hope they will soon start doing native builds of VMS.

They could start with just the Math RTL.

:-)

Arne

On 04/09/2023 22:23, John Reagan wrote:
> 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...@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.

Thanks for that - it is nice to see some of the hoops you have had to
jump through!

--
Chris

On Mon, 2023-09-04 at 14:23 -0700, John Reagan wrote:
> > 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?
>
> 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.

Thank you, that was most illuminating and interesting. I'm sure it
won't be long before OpenVMS x86 becomes self-hosting and capable of
building itself.

AMD Threadrippers (the newest ones) would be a perfect match.

Thanks, once again.
--
Tactical Nuclear Kittens

On 9/4/2023 7:10 PM, Single Stage to Orbit wrote:>
I'm sure it> won't be long before
OpenVMS x86 becomes self-hosting and capable of> building itself.> > AMD
Threadrippers (the newest ones) would be a perfect match.
The new 96 core 192 threads thingy?

Arne

On Monday, September 4, 2023 at 5:19:17 PM UTC-4, Craig A. Berry wrote:
> On 9/4/23 3:11 PM, 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...@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.
> But C++ is not part of the toolchain, at least not that I've ever heard
> of. And I doubt if much of the C code in VMS would compile with clang
> without modifications.
> > What did you use as the host to build the toolchains and all the x86_64
> > bits for VMS jut out of interest?
> John is the expert, but anyone following the roadmaps over the last
> several years knows that C++ is clang++ and the other compilers use a
> GEM compatibility layer to generate LLVM IR. And MACRO is special.
> > Is OpenVMS for x86 now self hosting
> > and can it build itself?
> Most of the compilers started out as cross compilers running on Itanium
> and as far as anything I've heard that's still what's in use for
> building the OS itself. All of the native compilers that are available
> are still in field test and likely to prioritize building customer code
> for now.
There is one C++ module in the Itanium COBOL RTL. SDL is written in C++
if you consider that part of the toolchain.

There are a handful of C++ modules in GEM but all but one can be easily
turned into C (which we had to do that for the initial native bootstrap)

For x86, there is a subset of LLVM inside of XMACRO so that is all C++ but
the MACRO.EXE is currently side-built and slipped into the V9.2/V9.2-1 kits..

And yes, all of the native compilers include G2L and LLVM (both in C++).

On 9/4/23 6:12 PM, Arne Vajhøj wrote:
> On 9/4/2023 5:19 PM, Craig A. Berry wrote:

>> But C++ is not part of the toolchain, at least not that I've ever heard
>> of.  And I doubt if much of the C code in VMS would compile with clang
>> without modifications.
>
> LLVM is C++ so on x86-64 I would consider C++ part of the VMS toolchain
> (strictly speaking toolchain to build toolchain, but ...).

Good point. I was thinking about what the OS itself is written in, but
I neglected the fact that you've got to have C++ to build LLVM to build
the C, BLISS, and MACRO compilers that build the OS.

> I hope they will soon start doing native builds of VMS.
>
> They could start with just the Math RTL.

.... which might fix the infinities not working on x86 that I posted
about a few days ago. Or that could be compiler problems or various
other things.

On 9/4/2023 8:21 PM, Craig A. Berry wrote:
> On 9/4/23 6:12 PM, Arne Vajhøj wrote:
>> I hope they will soon start doing native builds of VMS.
>>
>> They could start with just the Math RTL.
>
> ... which might fix the infinities not working  on x86 that I posted
> about a few days ago.  Or that could be compiler problems or various
> other things.

Per the VSI compiler guru there is also a problem with 128 bit return
values in the cross compilers.

Arne

On Monday, September 4, 2023 at 8:21:04 PM UTC-4, Craig A. Berry wrote:
> On 9/4/23 6:12 PM, Arne Vajhøj wrote:
> > On 9/4/2023 5:19 PM, Craig A. Berry wrote:
>
> >> But C++ is not part of the toolchain, at least not that I've ever heard
> >> of. And I doubt if much of the C code in VMS would compile with clang
> >> without modifications.
> >
> > LLVM is C++ so on x86-64 I would consider C++ part of the VMS toolchain
> > (strictly speaking toolchain to build toolchain, but ...).
> Good point. I was thinking about what the OS itself is written in, but
> I neglected the fact that you've got to have C++ to build LLVM to build
> the C, BLISS, and MACRO compilers that build the OS.
> > I hope they will soon start doing native builds of VMS.
> >
> > They could start with just the Math RTL.
> ... which might fix the infinities not working on x86 that I posted
> about a few days ago. Or that could be compiler problems or various
> other things.

Yeah, we're still dealing with some of that plus the exception mode feature used by
the math RTL to determine the exception behavior (some languages want different
behavior) is only just being fixed.

On Mon, 2023-09-04 at 19:21 -0500, Craig A. Berry wrote:
> On 9/4/23 6:12 PM, Arne Vajhøj wrote:
> > On 9/4/2023 5:19 PM, Craig A. Berry wrote:
>
> > > But C++ is not part of the toolchain, at least not that I've ever
> > > heard of.  And I doubt if much of the C code in VMS would compile
> > > with clang without modifications.
> >
> > LLVM is C++ so on x86-64 I would consider C++ part of the VMS
> > toolchain (strictly speaking toolchain to build toolchain, but
> > ...).
>
> Good point.  I was thinking about what the OS itself is written in,
> but I neglected the fact that you've got to have C++ to build LLVM to
> build the C, BLISS, and MACRO compilers that build the OS.

Spot on. This is what I call bootstrapping.

> > I hope they will soon start doing native builds of VMS.
> >
> > They could start with just the Math RTL.
>
> ... which might fix the infinities not working  on x86 that I posted
> about a few days ago.  Or that could be compiler problems or various
> other things.

All that'll be fixed in time.
--
Tactical Nuclear Kittens

On Mon, 2023-09-04 at 20:10 -0400, Arne Vajhøj wrote:
> The new 96 core 192 threads thingy?

Oh yes. Mighty aren't they? 

Intel did show off a 8-core processor with a total of _528_ threads the
other day, that's 66 threads per core using photonics.
--
Tactical Nuclear Kittens

On 2023-09-04, John Reagan <xyzzy1959@gmail.com> wrote:
>
> 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.
>

I was wondering if CMake on VMS was a reality yet. :-)

Are you hitting any specific problems with getting CMake to run on VMS, or
is getting CMake working just simply lower down the priority list, given
that you have the Linux-hosted workaround available ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-09-05 14:28, Simon Clubley wrote:
> On 2023-09-04, John Reagan <xyzzy1959@gmail.com> wrote:
>>
>> 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.
>>
>
> I was wondering if CMake on VMS was a reality yet. :-)
>
> Are you hitting any specific problems with getting CMake to run on VMS, or
> is getting CMake working just simply lower down the priority list, given
> that you have the Linux-hosted workaround available ?

I wouldn't be surprised if CMake is more of a headache than most
compilers. CMake is much more intimately interacting and interfacing
with the OS. A complier is mostly very OS unaware.

Johnny

On Tue, 2023-09-05 at 12:28 +0000, Simon Clubley wrote:
> On 2023-09-04, John Reagan <xyzzy1959@gmail.com> wrote:
> >
> > 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.
>
> I was wondering if CMake on VMS was a reality yet. :-)
>
> Are you hitting any specific problems with getting CMake to run on
> VMS, or is getting CMake working just simply lower down the priority
> list, given that you have the Linux-hosted workaround available ?

CMake doesn't know anything about VMS, especially file versioning.
That'll make it fun to port for the poor devil who's going to have to
do the work!
--
Tactical Nuclear Kittens