Heads-up: riscv64 build fails at `ink_queue.h` "unsupported processor" (no RISC-V freelist case)

[randomizedcoder]

G'day ATS team,

First off — thank you for Traffic Server. We're big fans of the project, and we've been working on packaging ATS 10 for Nixpkgs (the package set behind NixOS). Work-in-progress PR here: NixOS/nixpkgs#474177

While testing that package across a few architectures, we stumbled onto a small issue we thought was worth flagging — not urgent at all, purely a friendly heads-up for if/when RISC-V is on your radar.

What we saw

x86_64 and aarch64 build and run great (we tested aarch64 natively on real hardware). On riscv64 the build stops at:

include/tscore/ink_queue.h:177:2: error: #error "unsupported processor"

This reproduces both cross-compiling to riscv64 and building natively on a riscv64 board (SpacemiT K1). It's present on master as well as the 10.2.0-rc1 tag.

Why it happens

The lock-free freelist head in include/tscore/ink_queue.h chooses one of two strategies:

1. a generic path when the toolchain has a lock-free 128-bit CAS — #elif TS_HAS_128BIT_CAS (line ~127), or
2. an architecture-specific pointer-tagging layout, hand-coded only for x86_64 (line ~133) and aarch64 (line ~157); everything else hits the #else → #error (line ~177).

TS_HAS_128BIT_CAS is decided by cmake/Check128BitCas.cmake, which compiles:

int main(void) {
    __int128_t x = 0;
    return __sync_bool_compare_and_swap(&x, 0, 10);
}

On riscv64 there's no inline lock-free 128-bit CAS, so this lowers to a libatomic call and the probe fails to compile/link; the fallback retry uses -mcx16, which is x86-only. So TS_HAS_128BIT_CAS ends up off, and with no riscv64 branch in FREELIST_POINTER, the build falls through to the #error.

Possible directions (just ideas — you know the code far better than we do)

• Add a riscv64 case to the FREELIST_POINTER / FREELIST_VERSION / SET_FREELIST_POINTER_VERSION macros, analogous to the existing aarch64 block. One thing to watch: riscv64 Linux virtual-address width isn't fixed (Sv39 / Sv48 / Sv57), so the number of spare high bits available for the version counter varies — the aarch64 block assumes a 52-bit VA, whereas a conservative riscv64 layout might need fewer version bits.
• Or allow the generic TS_HAS_128BIT_CAS path on riscv64 (e.g. via libatomic), accepting that 128-bit CAS there may not be lock-free without the Zacas extension.

Either way, we didn't want to presume the right approach — mostly just wanted to put this on your radar.

Offer to help

We have a riscv64 board (SpacemiT K1) and a cross-compile setup, so we're very happy to test any patch on real RISC-V hardware if that's useful.

Thanks again for all the work on Traffic Server!

Environment

• ATS: 10.2.0-rc1 tag and master
• Arch: riscv64 (reproduced cross-compiling on x86_64 and natively on a SpacemiT K1)
• Toolchain: GCC (via Nixpkgs)