scripts/check_gcc.sh (#675) covers every Arm gnu port: 840 assembly sources, 469 re-assembled behind feature macros, 185 C sources across nine core profiles, 45 script-driven example builds and 5 CMake images. It does not cover ports/risc-v32/gnu or ports/risc-v64/gnu, which it prints by name in its skip list — the house rule being that a port absent from the count reads as covered.
This was deferred deliberately in #675 and said so in its body. This issue is to price and, if worth it, do it.
What is already known
Both RISC-V ports assemble cleanly with the project's own flags. Measured 24 Aug 2026: 8 of 8 and 8 of 8.
The flags must come from the project's existing CMake toolchain files rather than be invented:
cmake/riscv32_gnu.cmake — -march=rv32ima_zicsr -mabi=ilp32 -mcmodel=medanycmake/riscv64_gnu.cmake — -march=rv64gc -mabi=lp64d -mcmodel=medany
_zicsr is load-bearing. Without it, -march=rv32imac gives Error: unrecognized opcode 'csrw mepc,t0', extension 'zicsr' required on five files per port, which reads exactly like a broken port and is not.
Why it is not a small change
check_gcc.sh is built around two toolchains, arm-none-eabi and aarch64-none-elf, and:
cc_for switches on the target triple and would need a third arm for riscv-none-elf;- the script requires both toolchains to be present and exits 1 naming the missing one — that rule becomes "all three", which is a behaviour change for anyone running it locally with only the Arm toolchains;
gcc_check.yml would gain a third toolchain download and cache entry, tripling the cold-cache cost of the job.
So this is a design change to the script, not four more entries in a table.
Worth weighing
The RISC-V ports are not currently regressing, and the LLVM check does not cover them either. The argument for doing it is completeness and the fact that #576 is an open pull request adding a new RISC-V port — a check that existed would gate it. The argument against is a third toolchain in every run for a family that has not broken.
Follows from #675.
scripts/check_gcc.sh(#675) covers every Armgnuport: 840 assembly sources, 469 re-assembled behind feature macros, 185 C sources across nine core profiles, 45 script-driven example builds and 5 CMake images. It does not coverports/risc-v32/gnuorports/risc-v64/gnu, which it prints by name in its skip list — the house rule being that a port absent from the count reads as covered.This was deferred deliberately in #675 and said so in its body. This issue is to price and, if worth it, do it.
What is already known
Both RISC-V ports assemble cleanly with the project's own flags. Measured 24 Aug 2026: 8 of 8 and 8 of 8.
The flags must come from the project's existing CMake toolchain files rather than be invented:
cmake/riscv32_gnu.cmake—-march=rv32ima_zicsr -mabi=ilp32 -mcmodel=medanycmake/riscv64_gnu.cmake—-march=rv64gc -mabi=lp64d -mcmodel=medany_zicsris load-bearing. Without it,-march=rv32imacgivesError: unrecognized opcode 'csrw mepc,t0', extension 'zicsr' requiredon five files per port, which reads exactly like a broken port and is not.Why it is not a small change
check_gcc.shis built around two toolchains,arm-none-eabiandaarch64-none-elf, and:cc_forswitches on the target triple and would need a third arm forriscv-none-elf;gcc_check.ymlwould gain a third toolchain download and cache entry, tripling the cold-cache cost of the job.So this is a design change to the script, not four more entries in a table.
Worth weighing
The RISC-V ports are not currently regressing, and the LLVM check does not cover them either. The argument for doing it is completeness and the fact that #576 is an open pull request adding a new RISC-V port — a check that existed would gate it. The argument against is a third toolchain in every run for a family that has not broken.
Follows from #675.