Looks like new versions of C, Pascal and Fortran has just been released.

Arne

On Thu, 2023-11-16 at 07:22 -0500, Arne Vajhøj wrote:
> Looks like new versions of C, Pascal and Fortran has just been
> released.

Nice, thanks!
--
Tactical Nuclear Kittens

On 16/11/2023 22:52, Arne Vajhøj wrote:
> Looks like new versions of C, Pascal and Fortran has just been released.
>
> Arne

$ X86VMS$ cc/version
VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
$ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
/NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
/DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
/OBJ=[.obj_X86_64]Error Error.c
LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction

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

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 11/16/23 12:30 PM, Mark Daniel wrote:
> On 16/11/2023 22:52, Arne Vajhøj wrote:
>> Looks like new versions of C, Pascal and Fortran has just been released.
>>
>> Arne
>
> $ X86VMS$ cc/version
> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
> /OBJ=[.obj_X86_64]Error    Error.c
> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>
> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>

The error is strange, but shouldn't

/DEFINE(WASD_VMS...

be

/DEFINE=(WASD_VMS...

?

Den 2023-11-16 kl. 20:04, skrev Craig A. Berry:
> On 11/16/23 12:30 PM, Mark Daniel wrote:
>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>
>>> Arne
>>
>> $ X86VMS$ cc/version
>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>> /OBJ=[.obj_X86_64]Error    Error.c
>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>
>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>
>
> The error is strange, but shouldn't
>
> /DEFINE(WASD_VMS...
>
> be
>
> /DEFINE=(WASD_VMS...
>
> ?

It is, in the example on the forum post linked to above.

On 17/11/2023 05:34, Craig A. Berry wrote:
> On 11/16/23 12:30 PM, Mark Daniel wrote:
>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>
>>> Arne
>>
>> $ X86VMS$ cc/version
>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>> /OBJ=[.obj_X86_64]Error    Error.c
>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>
>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>
>
> The error is strange, but shouldn't

Search engine didn't reveal much of relevance.

> /DEFINE(WASD_VMS...
>
> be
>
> /DEFINE=(WASD_VMS...
>
> ?

And indeed it is. Laxity in cut-n-paste-n-realign from an 80 column
terminal. My regrets.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

On 17/11/2023 05:41, Jan-Erik Söderholm wrote:
> Den 2023-11-16 kl. 20:04, skrev Craig A. Berry:
>> On 11/16/23 12:30 PM, Mark Daniel wrote:
>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>> Looks like new versions of C, Pascal and Fortran has just been
>>>> released.
>>>>
>>>> Arne
>>>
>>> $ X86VMS$ cc/version
>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>> /OBJ=[.obj_X86_64]Error    Error.c
>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>
>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>>
>>
>> The error is strange, but shouldn't
>>
>> /DEFINE(WASD_VMS...
>>
>> be
>>
>> /DEFINE=(WASD_VMS...
>>
>> ?
>
> It is, in the example on the forum post linked to above.

Apparently also a laxity in consistency :-) Thanks J-E.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

In article <qdt5N.129064$ydda.38102@fx13.ams4>,
Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>On 16/11/2023 22:52, Arne Vajhøj wrote:
>> Looks like new versions of C, Pascal and Fortran has just been released.
>>
>> Arne
>
>$ X86VMS$ cc/version
>VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>$ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>/NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>/DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>/OBJ=[.obj_X86_64]Error Error.c
>LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>
>https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900

What's in `Error.c`? It's neither here nor on the VSI forum.

- Dan C.

On 17/11/2023 05:50, Dan Cross wrote:
> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>
>>> Arne
>>
>> $ X86VMS$ cc/version
>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>> /OBJ=[.obj_X86_64]Error Error.c
>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>
>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>
> What's in `Error.c`? It's neither here nor on the VSI forum.
>
> - Dan C.

I have not bothered to isolate a simple reproducer in anticipation of a
Reagan-esque, "oh that means...", or "I'll add that to the list". :-)

https://wasd.vsm.com.au/wasd_root/src/httpd/error.c

The error is reported across multiple modules and so relates to a common
header file construct or repeated code construct used individually.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

In article <m6u5N.135963$96D1.86705@fx04.ams4>,
Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>On 17/11/2023 05:50, Dan Cross wrote:
>> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>>
>>>> Arne
>>>
>>> $ X86VMS$ cc/version
>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>> /OBJ=[.obj_X86_64]Error Error.c
>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>
>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>
>> What's in `Error.c`? It's neither here nor on the VSI forum.
>
>I have not bothered to isolate a simple reproducer in anticipation of a
>Reagan-esque, "oh that means...", or "I'll add that to the list". :-)
>
>https://wasd.vsm.com.au/wasd_root/src/httpd/error.c
>
>The error is reported across multiple modules and so relates to a common
>header file construct or repeated code construct used individually.

I see. That program is, of course, somewhat long for a simple
reproduction. Out of curiousity, do you get a similar error
with something very simple, like "Hello, World?"

- Dan C.

On 17/11/2023 06:03, Dan Cross wrote:
> In article <m6u5N.135963$96D1.86705@fx04.ams4>,
> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> On 17/11/2023 05:50, Dan Cross wrote:
>>> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
>>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>>>
>>>>> Arne
>>>>
>>>> $ X86VMS$ cc/version
>>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>>> /OBJ=[.obj_X86_64]Error Error.c
>>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>>
>>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>>
>>> What's in `Error.c`? It's neither here nor on the VSI forum.
>>
>> I have not bothered to isolate a simple reproducer in anticipation of a
>> Reagan-esque, "oh that means...", or "I'll add that to the list". :-)
>>
>> https://wasd.vsm.com.au/wasd_root/src/httpd/error.c
>>
>> The error is reported across multiple modules and so relates to a common
>> header file construct or repeated code construct used individually.
>
> I see. That program is, of course, somewhat long for a simple
> reproduction. Out of curiousity, do you get a similar error
> with something very simple, like "Hello, World?"
>
> - Dan C.

No. And surely the product validation team would have the equivalent
test case in its suite ;-)

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

In article <Hcu5N.206704$OPFb.159654@fx15.ams4>,
Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>On 17/11/2023 06:03, Dan Cross wrote:
>> In article <m6u5N.135963$96D1.86705@fx04.ams4>,
>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>> On 17/11/2023 05:50, Dan Cross wrote:
>>>> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
>>>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>>>>
>>>>>> Arne
>>>>>
>>>>> $ X86VMS$ cc/version
>>>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>>>> /OBJ=[.obj_X86_64]Error Error.c
>>>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>>>
>>>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>>>
>>>> What's in `Error.c`? It's neither here nor on the VSI forum.
>>>
>>> I have not bothered to isolate a simple reproducer in anticipation of a
>>> Reagan-esque, "oh that means...", or "I'll add that to the list". :-)
>>>
>>> https://wasd.vsm.com.au/wasd_root/src/httpd/error.c
>>>
>>> The error is reported across multiple modules and so relates to a common
>>> header file construct or repeated code construct used individually.
>>
>> I see. That program is, of course, somewhat long for a simple
>> reproduction. Out of curiousity, do you get a similar error
>> with something very simple, like "Hello, World?"
>
>No. And surely the product validation team would have the equivalent
>test case in its suite ;-)

Well that's good, at least! The error message means that the
program is trying to store to one of the "high" "byte" registers
(AH, BH, CH, DH) with a REX-prefixed instruction; I don't know,
but this is almost certainly a MOV that requires a REX prefix
for access to the source operand: `movb (%r8), %ah` or something
like that. This is architecturally forbidden.

Why is it doing that? I'd imagine inline assembler would be the
most likely culprit, but I'm guessing there. I wonder if you
can get the compiler to emit an assembler listing?

- Dan C.

On 17/11/2023 06:20, Dan Cross wrote:
> In article <Hcu5N.206704$OPFb.159654@fx15.ams4>,
> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> On 17/11/2023 06:03, Dan Cross wrote:
>>> In article <m6u5N.135963$96D1.86705@fx04.ams4>,
>>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>>> On 17/11/2023 05:50, Dan Cross wrote:
>>>>> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
>>>>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>>>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>>>>> Looks like new versions of C, Pascal and Fortran has just been released.
>>>>>>>
>>>>>>> Arne
>>>>>>
>>>>>> $ X86VMS$ cc/version
>>>>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>>>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>>>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>>>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>>>>> /OBJ=[.obj_X86_64]Error Error.c
>>>>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>>>>
>>>>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>>>>
>>>>> What's in `Error.c`? It's neither here nor on the VSI forum.
>>>>
>>>> I have not bothered to isolate a simple reproducer in anticipation of a
>>>> Reagan-esque, "oh that means...", or "I'll add that to the list". :-)
>>>>
>>>> https://wasd.vsm.com.au/wasd_root/src/httpd/error.c
>>>>
>>>> The error is reported across multiple modules and so relates to a common
>>>> header file construct or repeated code construct used individually.
>>>
>>> I see. That program is, of course, somewhat long for a simple
>>> reproduction. Out of curiousity, do you get a similar error
>>> with something very simple, like "Hello, World?"
>>
>> No. And surely the product validation team would have the equivalent
>> test case in its suite ;-)
>
> Well that's good, at least! The error message means that the
> program is trying to store to one of the "high" "byte" registers
> (AH, BH, CH, DH) with a REX-prefixed instruction; I don't know,
> but this is almost certainly a MOV that requires a REX prefix
> for access to the source operand: `movb (%r8), %ah` or something
> like that. This is architecturally forbidden.

Yes. I had that gist from early search engine hits.

> Why is it doing that? I'd imagine inline assembler would be the
> most likely culprit, but I'm guessing there. I wonder if you
> can get the compiler to emit an assembler listing?

Excellent suggestion but unfortunately no. The compile must quit very
early. The object file has zero content precluding
ANA/OBJECT/DISASSEMBLE and while CC/LIST/MACHINE seems to be working
with this release the .LIS is similarly empty.

> - Dan C.
>

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

In article <tDu5N.98763$YBDd.93660@fx09.ams4>,
Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>On 17/11/2023 06:20, Dan Cross wrote:
>[snip]
>> Why is it doing that? I'd imagine inline assembler would be the
>> most likely culprit, but I'm guessing there. I wonder if you
>> can get the compiler to emit an assembler listing?
>
>Excellent suggestion but unfortunately no. The compile must quit very
>early. The object file has zero content precluding
>ANA/OBJECT/DISASSEMBLE and while CC/LIST/MACHINE seems to be working
>with this release the .LIS is similarly empty.

I'm mildly surprised by this: I'd imagine a compiler invocation
equivalent to `clang -S` on a Unix-y system would quite before
object generation; here, you just want to see what instructions
the compiler would generate without it actually trying to create
object code. I wonder if `CC/LIST/MACHINE/NOOBJECT` will do it?

You definitely ought to be able to get it to generate LLVM byte
code (which happens well before target instruction selection,
let alone object code generation) which may give some clues as
to what's going on.

- Dan C.

On 11/16/23 2:27 PM, Dan Cross wrote:
> In article <tDu5N.98763$YBDd.93660@fx09.ams4>,
> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> On 17/11/2023 06:20, Dan Cross wrote:
>> [snip]
>>> Why is it doing that? I'd imagine inline assembler would be the
>>> most likely culprit, but I'm guessing there. I wonder if you
>>> can get the compiler to emit an assembler listing?
>>
>> Excellent suggestion but unfortunately no. The compile must quit very
>> early. The object file has zero content precluding
>> ANA/OBJECT/DISASSEMBLE and while CC/LIST/MACHINE seems to be working
>> with this release the .LIS is similarly empty.
>
> I'm mildly surprised by this: I'd imagine a compiler invocation
> equivalent to `clang -S` on a Unix-y system would quite before
> object generation; here, you just want to see what instructions
> the compiler would generate without it actually trying to create
> object code. I wonder if `CC/LIST/MACHINE/NOOBJECT` will do it?
>
> You definitely ought to be able to get it to generate LLVM byte
> code (which happens well before target instruction selection,
> let alone object code generation) which may give some clues as
> to what's going on.

According to the known restrictions section in the release notes for the
field test compiler:

"The /MACHINE_CODE qualifier currently is ignored. As a
temporary workaround, you can use the
ANALYZE/OBJECT/DISASSEMBLE command."

Of course if you can't get an object file, that workaround ain't gonna work.

On 17/11/2023 06:57, Dan Cross wrote:
> In article <tDu5N.98763$YBDd.93660@fx09.ams4>,
> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>> On 17/11/2023 06:20, Dan Cross wrote:
>> [snip]
>>> Why is it doing that? I'd imagine inline assembler would be the
>>> most likely culprit, but I'm guessing there. I wonder if you
>>> can get the compiler to emit an assembler listing?
>>
>> Excellent suggestion but unfortunately no. The compile must quit very
>> early. The object file has zero content precluding
>> ANA/OBJECT/DISASSEMBLE and while CC/LIST/MACHINE seems to be working
>> with this release the .LIS is similarly empty.
>
> I'm mildly surprised by this: I'd imagine a compiler invocation
> equivalent to `clang -S` on a Unix-y system would quite before
> object generation; here, you just want to see what instructions
> the compiler would generate without it actually trying to create
> object code. I wonder if `CC/LIST/MACHINE/NOOBJECT` will do it?

As noted by Craig the notes state /MACHINE still unsupported (does
generate a very nicely presented source listing though :-) And no
object file.

> You definitely ought to be able to get it to generate LLVM byte
> code (which happens well before target instruction selection,
> let alone object code generation) which may give some clues as
> to what's going on.

A little LLVM in the HELP CC and nothing in SYS$HELP:CC.RELEASE_NOTES

CC /ARCHITECTURE
options to pass along to the LLVM code generator to select
CC /OPTIMIZE
options to pass along to the LLVM code generator to select

> - Dan C.

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

In article <Tsv5N.93490$rdid.19724@fx12.ams4>,
Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>On 17/11/2023 06:57, Dan Cross wrote:
>> In article <tDu5N.98763$YBDd.93660@fx09.ams4>,
>> Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote:
>>> On 17/11/2023 06:20, Dan Cross wrote:
>>> [snip]
>>>> Why is it doing that? I'd imagine inline assembler would be the
>>>> most likely culprit, but I'm guessing there. I wonder if you
>>>> can get the compiler to emit an assembler listing?
>>>
>>> Excellent suggestion but unfortunately no. The compile must quit very
>>> early. The object file has zero content precluding
>>> ANA/OBJECT/DISASSEMBLE and while CC/LIST/MACHINE seems to be working
>>> with this release the .LIS is similarly empty.
>>
>> I'm mildly surprised by this: I'd imagine a compiler invocation
>> equivalent to `clang -S` on a Unix-y system would quite before
>> object generation; here, you just want to see what instructions
>> the compiler would generate without it actually trying to create
>> object code. I wonder if `CC/LIST/MACHINE/NOOBJECT` will do it?
>
>As noted by Craig the notes state /MACHINE still unsupported (does
>generate a very nicely presented source listing though :-) And no
>object file.

Aww shucks; that's a bummer.

>> You definitely ought to be able to get it to generate LLVM byte
>> code (which happens well before target instruction selection,
>> let alone object code generation) which may give some clues as
>> to what's going on.
>
>A little LLVM in the HELP CC and nothing in SYS$HELP:CC.RELEASE_NOTES
>
>CC /ARCHITECTURE
>options to pass along to the LLVM code generator to select
>CC /OPTIMIZE
>options to pass along to the LLVM code generator to select

:-/ That's too bad.

- Dan C.

On 17/11/2023 06:01, Mark Daniel wrote:
> On 17/11/2023 05:50, Dan Cross wrote:
>> In article <qdt5N.129064$ydda.38102@fx13.ams4>,
>> Mark Daniel  <mark.daniel@wasd.vsm.com.au> wrote:
>>> On 16/11/2023 22:52, Arne Vajhøj wrote:
>>>> Looks like new versions of C, Pascal and Fortran has just been
>>>> released.
>>>>
>>>> Arne
>>>
>>> $ X86VMS$ cc/version
>>> VSI C x86-64 X7.4-843 (GEM 50XB9) on OpenVMS x86_64 V9.2-1
>>> $ CC /DECC /STAND=RELAXED_ANSI /PREFIX=ALL /NAMES=AS_IS /OPTIMIZE
>>> /NODEBUG /WARNING=(NOINFORM,DISABLE=(PREOPTW)) /FLOAT=IEEE /IEEE=DENORM
>>> /DEFINE(WASD_VMS_V7,SESOLA,WATCH_CAT=1,WATCH_MOD=0,WASD_ACME=1,WASD_GETSPI=1)
>>> /OBJ=[.obj_X86_64]Error    Error.c
>>> LLVM ERROR: Cannot encode high byte register in REX-prefixed instruction
>>>
>>> https://forum.vmssoftware.com/viewtopic.php?f=12&t=8900
>>
>> What's in `Error.c`?  It's neither here nor on the VSI forum.
>>
>>     - Dan C.
>
> I have not bothered to isolate a simple reproducer in anticipation of a
> Reagan-esque, "oh that means...", or "I'll add that to the list".  :-)

Boom-boom. Just posted in the VSI Forum:

"yeah, we saw it just a few days ago. Already fixed in our sources.
Can you try /NOOPT? It should avoid the bug."

It did and it does.

> https://wasd.vsm.com.au/wasd_root/src/httpd/error.c
>
> The error is reported across multiple modules and so relates to a common
> header file construct or repeated code construct used individually.
>

--
Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

I took the new C compiler for a spin and built Perl with it. I didn't
see any of the compiler errors Mark saw, but I got several undefined
symbols when linking that I did not previously get:

%ILINK-W-NUDFSYMS, 6 undefined symbols:
%ILINK-I-UDFSYM, C$_QSORT2BIG
%ILINK-I-UDFSYM, DECC$$GL___CRTL_VER_BUILD
%ILINK-I-UDFSYM, IN6ADDR_ANY
%ILINK-I-UDFSYM, IN6ADDR_LOOPBACK
%ILINK-I-UDFSYM, _NS_FLAGDATA
%ILINK-I-UDFSYM, _RES

C$_QSORT2BIG is declared in errnodef.h, DECC$$GL___CRTL_VER_BUILD in
unixlib.h, in6addr_any and in6addr_loopback in in6.h, _ns_flagdata in
nameser.h, and _res is in resolv.h.

So there is some kind of gear slippage among the compiler, the headers,
and the library. As far as I can see, the only thing new this week is
the compiler.

On 11/16/23 8:30 PM, Craig A. Berry wrote:
>
> I took the new C compiler for a spin and built Perl with it.  I didn't
> see any of the compiler errors Mark saw, but I  got several undefined
> symbols when linking that I did not previously get:
>
> %ILINK-W-NUDFSYMS, 6 undefined symbols:
> %ILINK-I-UDFSYM,        C$_QSORT2BIG
> %ILINK-I-UDFSYM,        DECC$$GL___CRTL_VER_BUILD
> %ILINK-I-UDFSYM,        IN6ADDR_ANY
> %ILINK-I-UDFSYM,        IN6ADDR_LOOPBACK
> %ILINK-I-UDFSYM,        _NS_FLAGDATA
> %ILINK-I-UDFSYM,        _RES
>
> C$_QSORT2BIG is declared in errnodef.h, DECC$$GL___CRTL_VER_BUILD in
> unixlib.h, in6addr_any and in6addr_loopback in in6.h, _ns_flagdata in
> nameser.h, and _res is in resolv.h.
>
> So there is some kind of gear slippage among the compiler, the headers,
> and the library.  As far as I can see, the only thing new this week is
> the compiler.

Upgrading from TCPIP X6.0-22 to TCPIP V6.0-23 did not make any
difference. I thought it might since some of the missing symbols are
TCP/IP-related.

Craig A. Berry <craigberry@nospam.mac.com> wrote:
> On 11/16/23 8:30 PM, Craig A. Berry wrote:
>> I took the new C compiler for a spin and built Perl with it.  I didn't
>> see any of the compiler errors Mark saw, but I  got several undefined
>> symbols when linking that I did not previously get:
>>
>> %ILINK-W-NUDFSYMS, 6 undefined symbols:
>> %ILINK-I-UDFSYM,        C$_QSORT2BIG
>> %ILINK-I-UDFSYM,        DECC$$GL___CRTL_VER_BUILD
>> %ILINK-I-UDFSYM,        IN6ADDR_ANY
>> %ILINK-I-UDFSYM,        IN6ADDR_LOOPBACK
>> %ILINK-I-UDFSYM,        _NS_FLAGDATA
>> %ILINK-I-UDFSYM,        _RES
>>
>> C$_QSORT2BIG is declared in errnodef.h, DECC$$GL___CRTL_VER_BUILD in
>> unixlib.h, in6addr_any and in6addr_loopback in in6.h, _ns_flagdata in
>> nameser.h, and _res is in resolv.h.
>>
>> So there is some kind of gear slippage among the compiler, the headers,
>> and the library.  As far as I can see, the only thing new this week is
>> the compiler.
>
> Upgrading from TCPIP X6.0-22 to TCPIP V6.0-23 did not make any
> difference. I thought it might since some of the missing symbols are
> TCP/IP-related.

I also saw she missing IN6ADDR_ANY when building ZeroMQ.

The TCP/IP shareables lack it, but it is exported from the TCP/IP libraries.

cu,
Martin

Let's see if I can help with all the questions.

- The "REX" issue is new due to the fact that we enabled a few more optimizations.
We have to capture the OpenVMS arg-count from the AH register (2nd byte of the
AX/EAX/RAX register). You cannot talk about AH in the same instruction with a
reference to the r8-r15 registers. We where trying to generate code that essentially
does

movb %ah, %al
movzbl %al, %r14d

The %r14d is a register picked by LLVM. We just ask for a "virtual register" (an
LLVM concept of a compiler temp). The sequence above is perfectly fine.
However, LLVM seemed to think it could "propagate" the first register usage into
the 2nd instruction and did

movb %ah, %al
movzbl %ah, %r14d

[it was then going to remove the movb instruction] That LLVM transformation is
based on information that we (the OpenVMS-specific changes to get the argcount)
provided. I think the LLVM transformation is broken but we also didn't provide the
correct information. Turn off optimization (or even /OPT=LEVEL=2) avoids it.

We just fixed the code to avoid that transformation.

- The "error.c" in the message is just the source module in LLVM that contained the
assert(). It has nothing to do with the user's source code, headers, etc.

- Those new undefined symbols are from additional debug information. If you look
future at the MAP, the unresolved reference isn't from generated code but from
DWARF in the .debug_info section. We shouldn't have generated the DWARF
for those declared, but uncalled/undefined external routines.

- /MACHINE_CODE is still not there since the "traditional" GEM machine code listing
contains more than just code. It also contains static data definitions AND has lots
of symbolic names. Most of that has been shuffled around inside of LLVM by the
point were we would like to grab it and stuff it into the LIS file. And some of the names
are long gone other than buried in DWARF (if available).

- As mentioned ANALYZE/OBJECT/DISASSEMBLE can dump the code along with
line numbers from the PC-line table. I've seen some issues with it printing "******"
in places for line numbers. We might spend more time on ANALYZE to improve the
output in the future.

- Right now, we have no extra qualifier to pass along any LLVM options other than
what we map from the traditional DCL qualifiers.

- There are a couple of undocumented qualifiers you might be curious about

/SWITCH=ASSEMBLY is the equivalent of -S on Linux. You get an .s file instead
of the .obj file. Much more than what ANAL/OBJ/DISA gives you.

/SWITCH=BITCODE is the equivalent of -emit-llvm on Linux. You get the .bc file
(bitcode file) instead of the .obj file. However, since bc files are LLVM version
specific, you'll need the llvm-dis from LLVM 10 to turn this into the human readable
..ll file. While we have all the LLVM tools in our build tree, we haven't yet decided how
(or if) to package them all up to provide to users. However, if you build LLVM 10 on
some Linux box, the llvm-dis toold should be able to convert the OpenVMS generated
..bc files.

On 11/16/23 11:51 PM, Martin Vorländer wrote:
> Craig A. Berry <craigberry@nospam.mac.com> wrote:
>> On 11/16/23 8:30 PM, Craig A. Berry wrote:
>>> I took the new C compiler for a spin and built Perl with it.  I didn't
>>> see any of the compiler errors Mark saw, but I  got several undefined
>>> symbols when linking that I did not previously get:
>>>
>>> %ILINK-W-NUDFSYMS, 6 undefined symbols:
>>> %ILINK-I-UDFSYM,        C$_QSORT2BIG
>>> %ILINK-I-UDFSYM,        DECC$$GL___CRTL_VER_BUILD
>>> %ILINK-I-UDFSYM,        IN6ADDR_ANY
>>> %ILINK-I-UDFSYM,        IN6ADDR_LOOPBACK
>>> %ILINK-I-UDFSYM,        _NS_FLAGDATA
>>> %ILINK-I-UDFSYM,        _RES
>>>
>>> C$_QSORT2BIG is declared in errnodef.h, DECC$$GL___CRTL_VER_BUILD in
>>> unixlib.h, in6addr_any and in6addr_loopback in in6.h, _ns_flagdata in
>>> nameser.h, and _res is in resolv.h.
>>>
>>> So there is some kind of gear slippage among the compiler, the headers,
>>> and the library.  As far as I can see, the only thing new this week is
>>> the compiler.
>>
>> Upgrading from TCPIP X6.0-22 to TCPIP V6.0-23 did not make any
>> difference. I thought it might since some of the missing symbols are
>> TCP/IP-related.
>
> I also saw she missing IN6ADDR_ANY when building ZeroMQ.
>
> The TCP/IP shareables lack it, but it is exported from the TCP/IP libraries.

As I mentioned in the forum thread here:

https://forum.vmssoftware.com/viewtopic.php?f=16&t=8898&p=19964#p19964

compiling /NOOPT makes the undefined symbol warnings go away. Which is
an unfortunate workaround but it's where we are until the next release I
guess.

On 11/16/2023 7:22 AM, Arne Vajhøj wrote:
> Looks like new versions of C, Pascal and Fortran has just been released.

And they just released Bliss!!

Arne

On 11/17/2023 2:28 PM, Arne Vajhøj wrote:
> On 11/16/2023 7:22 AM, Arne Vajhøj wrote:
>> Looks like new versions of C, Pascal and Fortran has just been released.
>
> And they just released Bliss!!

John and the compiler team have been working quite hard to get stuff out.

--

--- Rob