[Info-vax] VMS x86-64 compilers

[Dan Cross]

In article <Hcu5N.206704$OPFb.159654 at fx15.ams4>,
Mark Daniel  <mark.daniel at wasd.vsm.com.au> wrote:
>On 17/11/2023 06:03, Dan Cross wrote:
>> In article <m6u5N.135963$96D1.86705 at fx04.ams4>,
>> Mark Daniel  <mark.daniel at wasd.vsm.com.au> wrote:
>>> On 17/11/2023 05:50, Dan Cross wrote:
>>>> In article <qdt5N.129064$ydda.38102 at fx13.ams4>,
>>>> Mark Daniel  <mark.daniel at 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.