More whiny x86_64 CXX complaints (repackaged by request)

[sms]

Code: Select all

   Referring to the "OpenVMS x86-64 VSI C++ Release Notes Version:
230731"), and the compiler it came with...

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   1. CXX fails to preserve case of its own command line (assuming
SET PROCESS /PARSE_STYLE = EXTENDED).

> All message IDs should be given to CXX as they are in double quotes to
> preserve the case. This is true for the keyword "all" as well.

   If the C++ compiler preserved the case of _its_ command line, would I
be able to omit the quotation marks in, say:
       /warning = disable = ("dangling-else", "switch")
?

   Are there any messages which differ only in case, making a
case-insensitive comparison defective (now) or dangerous (some day)?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   2. /NAMES default "not [...] like all other OpenVMS compilers".

> The compiler does not automatically upcase external names like all
> other OpenVMS compilers. [...]

   The advantage of being "not [...] like all other OpenVMS compilers"
in this respect escapes me.  Especially when it complicates my
multi-architecture builders, where I now need to specify /NAMES
explicitly everyplace, or else add architecture-specific qualifiers on
x86_64.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

   3. Expected Predefined_Macros not defined.
   
ITS $ cc decc_ver.c /obj = decc_ver_i
ITS $ cxx dec_ver.cpp /obj = dec_ver_i
ITS $ link dec_ver_i, decc_ver_i
ITS $ run dec_ver_i
 __VMS_VERSION: >V8.4-2L3<.
 __VMS_VER    = 80421222.
 __DECC_VER   = 70490001.
 __DECCXX_VER = 70490005.
 __CRTL_VER   = 80500000.

V87 $ cc decc_ver.c /obj = decc_ver_x
V87 $ cxx dec_ver.cpp /obj = dec_ver_x /names = uppercase ! Grrr.
V87 $ link dec_ver_x, decc_ver_x
V87 $ run dec_ver_x
 __VMS_VERSION: (undefined).            [<--]
 __VMS_VER    = 2147483647.             [<--]
 __DECC_VER   = 70430785.
 __DECCXX_VER = (undefined).            [<--]
 __CRTL_VER   = 90210000.


   Regarding __DECCXX_VER:

V87 $ cxx /version
clang version 10.0.1 (git@bitbucket.org:vms_software/llvm-10.0.1.git c9f5780059da734fc743258839c4cdd956b28d51)
Build date: 07-31-2023
Target: x86_64-OpenVMS
Thread model: posix
InstalledDir: V87$DKA300:[SYS0.SYSCOMMON.][SYSEXE]

   That's all interesting, but a single VMS-style version number for
identification would fit better with existing stuff.

[jreagan]

1) It isn't the CXX command that upcases, it is DCL and the CRTL. You got half of the solution with

$ set process/parse=extended

to keep DCL out of the way, the CRTL still wants to touch the arguments. You can turn that off with

$ define DECC$ARGV_PARSE_STYLE ENABLE

but that might bother other C applications that are expecting the upcasing

2) I don't know of any message IDs that differ only in case. It all comes from LLVM/clang

3) RE: /NAMES default. We have received lots of pressure about being able to easily move open source code to OpenVMS with little/minimal changes. So far /NAMES=AS_IS is "better" than "uppercase". Neither has been perfect. We still can be persuaded to change the default

4) RE: predefined version symbols. I'll add that to the list for the team.

5) RE: "chatty" /VERSION output. That's pretty much what you get on Linux with "clang -v". The "single line" /VERSION output on the other compilers was just my first implementation with PASCAL years ago. The other compilers have copied (but somewhat diverged). We just went through ALL the compilers (other than C++) to make them more consistent (and still a single line). I've been tempted to add MORE to the other compilers to be honest. Do I want /VERSION=FULL or something?

[sms]

Code: Select all

> 1) It isn't the CXX command that upcases, it is DCL and the CRTL. [...]

   Sure, but the CRTL is subject to influence.

> > $ define DECC$ARGV_PARSE_STYLE ENABLE

   Which is why this complaint was initially included in a different
topic:

      https://forum.vmssoftware.com/viewtopic.php?f=12&t=8805

> but that might bother other C applications that are expecting the
> upcasing

   Which is why the _application_, CXX, in this case, rather than the
user, should set this option.  As is done, for example, in the Info-ZIP
programs:

V87 $ show logical DECC$*

(LNM$PROCESS_TABLE)

(LNM$JOB_827A4EC0)

(LNM$GROUP_000001)

(LNM$SYSTEM_TABLE)

  "DECC$CRTLMAP" = "SYS$SHARE:DECC$SHR"         <--- Not my idea.

(LNM$SYSCLUSTER_TABLE)

(DECW$LOGICAL_NAMES)
V87 $ set process /parse_style = extended
V87 $ show symbol zipv
  ZIPV == "$ SYS$COMMON:[SYSHLP.UNSUPPORTED.ZIP]ZIP.EXE"

   Now, note the different behavior with (unquoted) "-V" v. "-v":

V87 $ zipv -V

zip error: Invalid command arguments (cannot write zip file to terminal)

V87 $ zipv -v
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
[...]

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

> 2) I don't know of any message IDs that differ only in case. It all
> comes from LLVM/clang

   I figured.  I guess that the question is whether those folks have (or
could easily be persuaded to have) a policy in this regard.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

> 3) RE: /NAMES default. [...] We still can be persuaded to change the
> default

   As I said, adding /NAMES=AS_IS to the builders for _programs_ which
need it works better for me than adding complexity to the builders for
a particular hardware architecture.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

> 5) RE: "chatty" /VERSION output. [...] Do I want /VERSION=FULL or
> something?

   _I_ think that you do.  (Of course, I'm not doing the work.)  But
mostly, having __DECCXX_VER disappear was a surprise.

[jreagan]

Sorry for the delay.

As for why CXX does not set

$ define DECC$ARGV_PARSE_STYLE ENABLE

directly is that we don't do that on Itanium and we are trying to "match the behavior".

Of course, you can say that matching the existing behavior is silly if the behavior is wrong. Setting that option has to be done very early in some LIB$INITIALIZE section since the processing of the argc/argv vectors is done prior to the starting of "main()". I'll see if the team can figure that one out. Enabling the parse-style can change the behavior of existing scripts.

As for the various predefined symbol names: we are working on the HELP file ($ HELP CXX LANGUAGE_TOPICS PREDEFINED_MACROS) and well as a big revision of the C++ User Manual (which has several tables and discussions about those symbols). The __DECCXX and __DECCXX_VER macros, we haven't been setting them since we have viewed the clang-based compiler as NOT DEC CXX language. It doesn't have all the features as DEC[sic] C++ on Alpha or Itanium. People have used those symbols to enable source code to use certain features. __DECCXX_VER in particular is checked in the headers to enable many features. For code that wants to know "C vs C++", you should check the __cplusplus and __STDC_VERSION__ symbols.