Prod feedback flagged that `list_compilers(match="gcc 16",
instructionSet="amd64", latestPerMajor=true)` returned only
hppag1610, dropping the actual x86-64 g161. Two layered causes,
both fixed:
1. The HPPA cross-compilers were tagged `instructionSet=amd64`
because there was no `hppa` value in `InstructionSetsList`. Added
`hppa` to the closed enum (and to `InstructionSets` runtime
support with `target=['hppa']`). Set `instructionSet=hppa` on
every HPPA group across c++, c, ada, d, fortran, gimple, objc,
objc++ (~32 compilers).
2. While auditing for other mis-tags, found the Go cross-compilers
are similarly mis-tagged: arm64_gl* / mips_gl* / s390x_gl* /
386_gl* / arm_gl* / ppc64_gl* / ppc64le_gl* / riscv64_gl* /
wasm_gl* (~150 compilers across 12 groups, all defaulting to
amd64). Set the proper `instructionSet` on each group: x86,
arm32, aarch64, mips, powerpc, riscv64, s390x, wasm32.
3. Defensive fix in `pickLatest` (lib/mcp/tools/compilers.ts):
include `compiler.group` in the stable-bucket key so different
compiler families that happen to share an arch tag never compete
for the same `(lang, arch, semverMajor)` slot. This is the
structural root cause of the original bug — even with the
config fixes above, future mis-tagged compilers shouldn't be
able to silently hijack another family's slot. New test
asserts that two compilers with identical `(lang, arch, major)`
but different `group` both survive `latestPerMajor`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1947bea791