Some minor C/CXX questions

[mberryman]

1. Will CXX/clang always continue to create only uppercase module names or will they eventually be changed to match what the C compiler does? This mainly affects my MMS scripts.

1a. If the answer to the above question is yes, please consider this a request to add an uppercasing function to MMS.

2. Is there any way to tell from __DECC_VER whether or not the compiler is an X or V version? I'm looking for a way to determine this programmatically. An example:
$ magick -version
Version: ImageMagick 7.1.1-14 Q16-HDRI x86_64 21286 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI
Delegates (built-in): bzlib freetype gslib jbig jng jp2 jpeg lcms png ps tiff webp x xml zlib
Compiler: VSI C 7.4-785

[sms]

Code: Select all

> 1. Will CXX/clang [...]

      cxx /version

> [...] always continue to create only uppercase module names or will
> they eventually be changed to match what the C compiler > does? [...]

   You lost me.  _My_ complaint about CXX on X86_64 (so far) is that, by
default, it does _not_ "create only uppercase module names".  See:

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

Specifically, item:

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

> [...] This mainly affects my MMS scripts.

   I'd say that it affects compiler commands, whether or not they appear
in MMS descriptions.

> [...] please consider this a request to add an uppercasing function to
> MMS.

   If the compiler is the problem, then how would _MMS_ know when to do
what?  (But one might interpret this as a (another) vote for making the
new CXX "like all other OpenVMS compilers" with respect to the /NAMES
default.)

   My first venture into C++ on x86_64 included, for example:

.IFDEF __X86_64__               # __X86_64__
LINKER = LINK                       # (As opposed to "CXXLINK".)
CXXFLAGS_ARCH = /names = uppercase \
 /pointer_size = long = argv \
 /warning = disable = ("dangling-else", "switch")
.ENDIF                          # __X86_64__

And then CXXFLAGS_ARCH gets folded into CXXFLAGS, along with a host of
other CXXFLAGS_xxxx macros.


> 2. Is there any way to tell from __DECC_VER whether or not the
> compiler is an X or V version? [...]

   The "VSI C for OpenVMS User Guide" shows different codes for "T" (6),
"S" (8), and "V" (9), with nothing for "X".

      https://docs.vmssoftware.com/docs/vsi-c-user-s-guide-for-openvms-systems.pdf#%5B%7B%22num%22%3A1811%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C90%2C696.074%2Cnull%5D

   I know nothing, but see that previously cited forum topic.  For
example:

   IA64:
                   v-------- 9 = "V"
 __DECC_VER   = 70490001.
 __DECCXX_VER = 70490005.

   x86_64:
                   v-------- 3 = "X"?
 __DECC_VER   = 70430785.
 __DECCXX_VER = (undefined).

   Not having a __DECCXX_VER defined makes it tough to say much about
that one.

> [...] I'm looking for a way to determine this programmatically. [...]

   When in doubt, capture the output from a "cc /version" command, and
stick it into some C code (header file, function module, ...)?

[hb]

You lost me: "With my weak psychic powers (and/or laziness), I can't see what you did, or what happened when you did it." What are the complaints? SYMBOL names, MODULE names or OBJECT file names? And what is the relationship between SYMBOL names and MMS?

On x86 with current compilers, ...

By default, MODULE names are in UPPERCASE, no matter if compiled by C or CXX. Only C with /NAME=AS_IS keeps the module name as is. By default OBJECT file names are in UPPERCASE for CXX, and they are "as_is" for C - as the name of the source file for C. (If you want/need mixed case OBJECT file names, you obviously need to have extended parsing set for the process and to be on an ODS-5 volume to create a mixed case source file name, and you need to have no other version of the object file around - otherwise C will just create a new version -- unless you have case sensitivity enabled, but that will very likely cause other problems.)

Should this be changed and should this be made more consistent? Yes, it should.

Actual commands and their output (in a code box, which makes the rest of my comments more readable for those who do not have/use large browser windows and have sliders around the code box).

Code: Select all

$ cxx/version
clang version 10.0.1 (git@bitbucket.org:vms_software/llvm-10.0.1.git 1944c289616bb7073af92c05d3ba6e7fd5d7ed0e)
Build date: 09-01-2023
Target: x86_64-OpenVMS
Thread model: posix
InstalledDir: HBX$DKC400:[SYS0.SYSCOMMON.][SYSEXE]
$ 
$ cre anExample.cxx
extern "C" {
void inCaseItIsACamel(void){}
}
 Exit 
$ cxx anExample
$ dir anExample

Directory SYS$SYSROOT:[SYSMGR]

anExample.cxx;1     ANEXAMPLE.OBJ;1     

Total of 2 files.
$ pipe analyze/obj anExample |search sys$pipe "module name"
    Module name:                                "ANEXAMPLE"
$ pipe analyze/obj anExample /section=symtab |search sys$pipe "incase
000003B0 00000090  Symbol 6. (00000006)          "inCaseItIsACamel"
$ delete anExample.obj;*
$
$ cc/ver
VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 XGJT-K6N
$ cre anExample.c
void inCaseItIsACamel(void){}
 Exit 
$ cc anExample
$ dir anExample

Directory SYS$SYSROOT:[SYSMGR]

anExample.c;1       anExample.cxx;1     anExample.OBJ;1     

Total of 3 files.
$
$ pipe analyze/obj anExample |search sys$pipe "module name"
    Module name:                                "ANEXAMPLE"
$ pipe analyze/obj anExample /section=symtab |search sys$pipe "incase
00000358 000000F0  Symbol 10. (0000000A)          "INCASEITISACAMEL"
$
$ cc anExample/name=as_is
$ pipe analyze/obj anExample |search sys$pipe "module name"
    Module name:                                "anExample"
$ pipe analyze/obj anExample /section=symtab |search sys$pipe "incase
00000358 000000F0  Symbol 10. (0000000A)          "inCaseItIsACamel"
$ 

[sms]

Code: Select all

> You lost me: [...]

   Which "You" is that?

> What are the complaints? [...]

   _My_ complaints are explained in that previously cited thread.  One,
which affects linking CXX objects with non-CXX objects, is that, as the
CXX release notes say, "The compiler does not automatically upcase
external names like all other OpenVMS compilers."  Which requires the
CXX user to specify /NAMES = UPPERCASE explicitly on x86_64 to get the
same behavior as CXX on other hardware architectures.

   I'm guessing that that's the case-related problem which troubled the
person who started this topic.

   I doubt that most people care much about the case of object file
names, but when a LINK fails with a bunch of USEUNDEF complaints on
x86_64, when that same build procedure worked on, say, IA64, I'd expect
that to draw some attention.  (It certainly got mine.)

   If you want a demonstration, then see item 3 in that previously cited
thread, and try it using the _same_ C and CXX commands on both IA64 and
x86_64.

[mberryman]

No, I am not talking about symbol names. I am talking about the module name as recorded in the object file (which one can specify in C using the #pragma module statement). It affects MMS because all previous C and C++ compilers set the module name equal to the filename (at least they do when compiled with /names=as_is, which is how I compile everything). However, the clang based C++ compiler sets the module name to all uppercase, regardless of the setting of /names.

How does this affect MMS? Consider a description file built as follows:
OBJS : testModule=$(OBJDIR)testModule.obj

$(OBJDIR)testModule.obj : [.src]testModule.cpp

This works great on Alpha and Itanium. On x86, MMS complains that the object module did not update the library. If I change it to:

OBJS: TESTMODULE=$(OBJDIR)testModule.obj

It will work without error on x86 but complain on both Alpha and Itanium. I'd really rather not need different MMS files for x86 and MMS currently provides no way to convert anything to uppercase within the script.

So I posed a question that was supposed to mean: will the clang based compilers ever set the module name the same way previous compilers have done?