From: arne@vajhoej.dk   
      
   On 3/27/2025 6:22 PM, John Reagan wrote:   
   > Yes, we are currently using clang/LLVM 10.0.1.  It is bootstrapped using   
   > a Linux version of the same code base with changes to create OpenVMS   
   > objects (it knows about CRTL name mapping, argcounts, and all that   
   > stuff).  What we did was:   
   >   
   > - start with the plain 10.0.1 sources and 10.0.1 binaries   
   > - add code to clang/LLVM (much of the LLVM changes were just carried   
   > over from the LLVM 3.4.2 codebase we used with the cross compilers)   
   > - build that code on Linux creating a 10.0.1v compiler   
   > - use that compiler to build it all again   
   > - copy all the .o files over to an OpenVMS machine to put into OLBs   
   > - link clang using those OLBs on OpenVMS   
   > - use that clang on OpenVMS to build our G2L (GEM to LLVM converter)   
   > - link all the legacy frontends (originally build with cross compilers   
   > but now built with native compilers) with the G2L and LLVM libraries   
   > - test & make kits   
   > - and Bob's your uncle and much easier than learning to say the French R   
   > sound   
      
   Ah - so 3.4.2 was only Itanium cross compiling while native use 10.0.1 -   
   that makes a release even more interesting!!  :-)   
      
   > As for native building, we do have a CMake ported and are currently   
   > working on native building that 10.0.1v source tree on OpenVMS V9.2-3   
   > including some work to CMake to make it easier for symbol vector   
   > management for LIBCXX/LIBCXXABI.  Not quite to testing yet.   
      
   Do you plan on releasing CMake for VMS?   
      
   Please say yes.  :-)   
      
   > We have also downloaded the latest LLVM (either 20.1.0 or 20.1.1, I'd   
   > have to go check).  As a first step, we've been able to compile that on   
   > Linux using the same 10.0.1v compiler that we use today.  The LLVM 20   
   > code base is much larger as you can imagine and we're working on linking   
   > up the LIBCXX/LIBCXXABI libraries right now.  The number of LLVM   
   > libraries is also different.  We've merged in some but not all of the   
   > OpenVMS additions but nothing tested yet.  We'll have to upgrade our G2L   
   > since the internal LLVM IR is not guaranteed to be upward compatible and   
   > they've changed several of the interfaces over the last few years.  And   
   > to make it even more painful, LLVM 20 now requires a newer CMake version   
   > than the one we ported.  Ugh!  We'll do it again and then look at   
   > providing it online as well.   
   >   
   > As for merging our code back into the actually LLVM repo, that's still a   
   > work in progress.  Once we switch to LLVM 20, we will be in a much   
   > better position to make the case to the LLVM community.  I think it will   
   > be an easier discussion for the LLVM changes.   
      
   Obviously.   
      
   But it will also take longer time.   
      
   >                                                The clang changes might   
   > be a tougher sell since our addition of dual-sized pointers, listing   
   > files, etc might scare off a few people. It would be difficult for the   
   > build bots to build (we would have to provide and manage some systems).   
      
   I don't think clang changes are as interesting as LLVM changes.   
      
   You provide C and C++. No point in community to do another C or C++.   
      
   But maybe (just maybe) the community could do some languages that   
   VSI does not provide utilizing the LLVM backend.   
      
   > Making our VSI git repositories visible would be another choice.   
   > However, if you haven't noticed,   
   >   
   > https://arstechnica.com/gadgets/2025/03/google-makes-android-   
   > development-private-will-continue-open-source-releases/   
      
   Google & Android and VSI & VMS are in very different states.   
      
   > Besides the sources (and scripts), I'd like to make another kit of pre-   
   > built images (and perhaps the LLVM libraries) that come out of the LLVM   
   > build today.  There are some of the LLVM tools that are only useful to   
   > compiler developers like llvm-dis but there are some tools like clang-   
   > format, llvm-objdump, llvm-dwarfdump, llvm-nm, etc that others might   
   > want.  For example, the X86ASM product on the support portal is just the   
   > llvm-mc tool.  llvm-mc is quite powerful as both an assembler AND   
   > disassembler.  It can even convert between AMD and Intel syntax as a   
   > party trick.   
      
   Go for it!   
      
   Please.   
      
   > G2L, while completely written by VSI, would only be useful if you have a   
   > compiler frontend that generates GEM CIL.  And G2L does use GEM headers   
   > so that's where the existing HPE copyrights start to appear.   
      
   Are there any non-VSI compilers using GEM? Kednos PL/I? Synergex DBL?   
      
   If there are then maybe some interest. Assuming IPR can be worked out.   
      
   Not relevant for the "new stuff".   
      
   > Vi ses snart i Malmö   
      
   :-)   
      
   Arne   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)