Add a self-hosting AArch64 backend

[jserv]

Adds AArch64 Linux as a fourth target, generating ELF64 images under AAPCS64 in both static and dynamically linked form, with the stage-1 and stage-2 compilers byte identical. The backend maps the allocator's registers onto x0-x7 and x20-x22, keeps the synthetic global frame in x19, and reaches libc through an eager-bound PLT of ADRP/ADD/LDR/BR entries. Images separate their load segments by 64 KiB so they stay loadable under any of the granules AArch64 Linux may use.

A 64-bit pointer did not survive two assumptions the 32-bit targets had shared. The register allocator now records which operand of an arithmetic instruction is an address, because pointer arithmetic has to widen the int index beside it, and the global-frame slot reserves a full pointer rather than the historic 32-bit word. Both are inert on arm, riscv and x64. Separately, the diagnostic paths now flush every stream before the compiler exits: a dynamically linked build resolves fflush through the PLT to the host libc, but lib/c.h defines stdout as the plain descriptor 1, so the old code handed glibc address 1 to dereference.

The shared suite gains cases for narrow signed values and for pointer truthiness, neither of which it covered before; a pointer has to be tested over its whole value, which only starts to matter once a target holds one in a register wider than an int. README names the new target alongside the other three, and the CI matrix runs it in both link modes.

Verified locally on x86-64: make check passes for arm, riscv, x64 and arm64 statically linked, and for arm64 with DYNLINK=1, each including the stage-1/stage-2 byte-identity check. The AAPCS64 ABI suite reports 12/12 at stage 0 and stage 2 in both link modes.

Two things are deliberately out. QEMU-user on an x86-64 host always presents 4 KiB pages, so neither CI nor the local runs can observe the 64 KiB segment separation actually mattering; that needs real hardware with a larger granule. And writing the array form of the narrow-signed test exposed a defect in the Arm backend, where char elements load zero-extended, so that case stays in the AArch64 gate rather than breaking the shared suite. Fixing the Arm backend belongs in its own change.

---

Summary by cubic

Adds a self-hosting AArch64 Linux backend that emits static and eager-bound dynamic ELF64 binaries under AAPCS64. This expands support beyond ARMv7, RV32, and x86-64 while keeping stage-1 and stage-2 output byte-identical.

New Features

• Maps compiler registers to AAPCS64 registers, preserves the global frame in x19, and emits AArch64 PLT entries.
• Separates load segments by 64 KiB so binaries work with 4 KiB, 16 KiB, and 64 KiB AArch64 Linux translation granules.
• Adds AArch64 ABI tests and runs both link modes across CI; Linux Arm64 runners execute the target natively, while x86-64 dynamic runs need gcc-aarch64-linux-gnu, qemu-aarch64, and a matching sysroot.

Bug Fixes

• Tracks pointer and array operands so pointer arithmetic sign-extends integer indices and pointer conditions use all 64 bits.
• Stores global-frame pointers and GOT entries at the target pointer width.
• Flushes all streams before compiler diagnostics exit and marks generated output files executable.
• Keeps the narrow signed array test AArch64-only because the existing Arm backend zero-extends char loads.

^{Written for commit 83672e1. Summary will update on new commits.}

[DrXiao]

I think chmod +x fib should be preserved because the generated ELF file is not executable by default. Therefore, chmod is still necessary.

Otherwise, the following error may occur:

$ qemu-arm -L /usr/arm-linux-gnueabihf/ fib
Error while loading /home/drxiao/workspace/sysprog/shecc/fib: Exec format error

[DrXiao]

I think the host-arm job could also be extended to validate the AArch64 backend (through native execution).