[Info-vax] C99 stuff (Re: The Road to V9.0)

[John Reagan]

On Friday, June 7, 2019 at 10:18:02 AM UTC-4, clair... at vmssoftware.com wrote:
> On Friday, June 7, 2019 at 9:54:21 AM UTC-4, Bob Gezelter wrote:
> > WADR, while large components of the existing user base are comprised of FORTRAN, PASCAL, COBOL, and BASIC, I have found that even in installations which are based on "classic" languages, there are dependencies on C/C++. Often these dependencies are in the areas of supporting toolchains (e.g., ZIP/UNZIP, Apache, etc.). I note John's earlier posting on the question of native C++ using LLVM.
> > 
> > Admittedly without proof, I suspect that many ISVs and end-users will discover that the lack of native C/C++ is an impediment. Direction/guidance in this regard would likely be welcomed.
> > 
> > - Bob Gezelter, http://www.rlgsc.com
> 
> Understood. I have the language requirements from all those interested in 9.0 and many use C++. However, we cannot get C++ ready for 9.0 so we will select participants who do no need it or can live without it for a while. C++ on x86 is a huge project and will be far behind the other languages. That's just the way it is. (BTW: Those who answered the questionnaire knew the C++ situation when they replied.)

I've discussed the C++ logistics before...

While LLVM 3.4.2 can be pushed through the OpenVMS Itanium C++ compiler (that compiler is barely C++03 compliant), clang 3.4.2 simply won't compile.  It uses lots of templates and template specializations that the Itanium C++ just won't swallow.  I pushed and pushed.  I sought advice from experts in the LLVM community.  I came close to calling a psychic.  

I'm pretty sure that they are bugs in the Itanium C++ compiler but it might be that clang 3.4.2 uses some template features from C++11 in spite of belief that 3.4.2 is C++03 compilable.  Dunno.  

Without that, we have no Itanium-hosted C++ frontend to attach to LLVM.  The Itanium frontend doesn't generate either LLVM IR or GEM IR (plus our old license with Intel with that frontend prevents porting it anywhere else).  The even older Alpha C++ frontend and matching STL is a non-starter and would be a total waste of time to interface to the GEM to LLVM converter.

We are in the process of partially building a newer clang/llvm (using version 8.0.0 at the moment, but that will advance as time goes forward) on a Linux box and will move those objects back to OpenVMS Itanium to push through the cross-linker.  We also have to cross-compile/cross-link the LLVM libcxx (standard template library), the LLVM libcxxabi (C++ TRY/EXCEPT exception handling), and the LLVM compiler-rt library (their version of LIBOTS with a bunch of utility routines that might be called from LLVM generated code).  None of this was needed for Macro, BLISS, or C.  

Even if we were able to build clang 3.4.2 with the Itanium C++ compiler, we'd have to spend the time to port over the 3.4.2 equivalents of libcxx, libcxxabi, and compiler-rt just to throw them all away when moving to the much newer versions of clang/LLVM for native compilers.  Seems like a waste of resources to me.