Pascal X6.3-137

[martinv]

Now that the native PASCAL compiler for x86_64 is out, the first thing I tried it out on was our in-house developed ERP system. Unfortunately, it fails on the third file compiled with a non-meaningful - at least, to me - LLVM error message. The module compiled is just a bunch of procedures to read and write FAT-formatted floppy disks (yes, I know. It shows the age of the system...)

Code: Select all

Build started on x86_64 at  9-MAY-2023 09:52:32.58
Compiling TSTP:CKDEF.PAS to GUIPENDBG:CKDEF.PEN  (0)
Compiling FRD:MSDEF.PAS to GUIPENDBG:MSDEF.PEN  (0)
Compiling TSTP:DOSLIB.PAS to GUIPENDBG:DOSLIB.PEN  (0)
assert error: expression = PointeeType == cast<PointerType>(Ptr->getType()->getScalarType())->getElementType(),
 in file /llvm$root/include/llvm-project-10/llvm/include/llvm/IR/Instructions.h at line 945
VSI Pascal Fatal Error has occurred
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFF830008F336AF, PS=0000001B

  Improperly handled condition, image exit forced.
    Signal arguments:   Number = 0000000000000003
                        Name   = 0000000000000434
                                 FFFF830008F336AF
                                 000000000000001B
    Register dump:
    RAX = 0000000000002EFA  RDI = 0000000000000434  RSI = 0000000000000000
    RDX = 0000000000000000  RCX = 00000000FFFFFFFA  R8  = 0000000000000000
    R9  = 0000000000000000  RBX = 0000000003DE98B0  RBP = 000000007ACC1660
    R10 = 0000000000000001  R11 = 0000000000000206  R12 = 00000000038AD878
    R13 = 0000000000000080  R14 = 0000000003DE98B0  R15 = 000000007ACC34E8
    RIP = FFFF830008F336AF  RSP = 000000007ACC15A0  SS  = 000000000000001B

Also, no listing file is produced in that case. I already fixed some sloppy programming with respect to $FILESCAN in that file, but am at a loss where to look for further problems. Anyone?

TIA,
Martin

P.S.: Also opened a case SPS-1052

[jreagan]

Thanks for the support ticket. I'll look at this soon (I've seen it from another customer already). There is clearly something in the LLVM IR that we generate. I'll let you know if there is a workaround or if I can just fix it and an update the compiler quickly.

John