[Info-vax] C and C++ and clanger-free clanging (was: Re: Porting to Linux instead of x86-64 VMS, ...)

[John Reagan]

On Wednesday, July 3, 2019 at 1:54:44 PM UTC-4, Stephen Hoffman wrote:
> On 2019-07-03 16:15:42 +0000, John Reagan said:
> 
> > Beyond that, I can't do a DCL "syntax" change on /STANDARD=C11.  I 
> > could try something like "CC/CLANG" or "CC/C11" that would turn around 
> > an attempt to invoke clang with the "you are a C compiler and accept 
> > C11 code" but I find that ugly.  My current plan is say "invoke 
> > SYS$SYSTEM:CLANG.EXE" (or whatever we decide on the final name) as a 
> > DCL foreign command.
> 
> Okay, the phrasing here is somewhat ambiguous.  Are you referring to 
> making a syntax switch from DCL to a foreign-command, or are you 
> discussing the default compilation mode for C code invoking the C 
> compile absent a specific /STANDARD selection?
> 
> Absent a specific selection, the default standard was the newest, IIRC. 
>  That hasn't been tripping folks since shortly after 1999 and for what 
> should be obvious reasons, but there was an assumption that developers 
> would have to add switches to accept old and now-deprecated standards.  
> And I see no reason not to make C11 the default, if there's no C18 and 
> thus C11's the newest available.
> 
> That it's two separate compilers with two separate licenses has been 
> tripping new-to-OpenVMS developers for some time.
> 
> If it's around the compiler switches and changing from DCL parsing 
> syntax to clang's own switch syntax?    For those that don't want to do 
> that and just want to add a few, /CLANG="-Wall-Wextra -pedantic", 
> maybe.  But then I'll probably be dropping down to the clang command 
> line directly.  Which is where I think you're headed, if this is about 
> DCL command parsing and not about C standards and source code parsing...
> 
> > My experience is that most people care about newer C++ standards, not 
> > about C11 or C18.  The only C11 feature I've been asked about is 
> > "static_assert".  I'd be willing to cherry-pick that one and put that 
> > into our C frontend.  Most of C11 is atomic and threading which can be 
> > done with C++.
> > 
> > For a good description, read:
> > 
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3631.pdf
> 
> Yeah, the Dr Dobb's article is a pretty good one.
> 
> Also see: 
> https://smartbear.com/blog/test-and-monitor/c11-a-new-c-standard-aiming-at-safer-programming/ 
> 
> 
> There's stuff there that I've been using else-platform.  Or 
> occasionally back-porting to OpenVMS.  Better support for turd files, 
> too.
> 
> Re-reading the C manuals every few years was handy, given what was 
> being added in the latter parts of V7 and into the early V8 range.
> 
> Getting threading integrated with KP threads and maybe also with 
> gcd/libdispatch and with the blocks/closures support would be nice.  
> Better threading than what is available.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

I was talking about the "syntax" clause in the .CLD file.  I'd like /STANDARD=C11 to invoke a different image.  I could make it really twisty and have the legacy VSI C compiler do a LIB$DO_COMMAND of clang-as-a-C11-compiler when /STAND=C11 is set.

The problem with that is that clang-as-a-C-compiler will never support lots of pragmas that the legacy C compiler does.  It seems too confusing to magically switch the compiler out from under you with a /STANDARD qualifier option.  I want to make it clear that asking for C11 means a different compiler.  If you want to move into the future (er, past) with C11, it means you have to let go of the legacy tree.  Of course, open source software coming to OpenVMS for the first time won't use any of those old DEC features.

For the CXX DCL interface to clang++, I don't see us providing an arbitrary /CLANG_OPTIONS="random string".  We'll provide a reasonable mapping for the existing DCL syntax for the "recompile-and-go" crowd.  We'll probably add some support for various common hardware flavors with /ARCH.  Maybe a few others.  But if you want to specific lots of strange exotic options, use the foreign command form.  That said, if you compile without -fPIC (and perhaps a few other ones), the object probably won't link/execute correctly.  In order to support shareable images, INSTALL/RESIDENT, etc., you must compile with -fPIC.  The DCL interface will set that for you.  We'll provide guidance when the time comes.