[ondrik]

Stacked on #48 and #47, which hold the build fixes this probe found (the whole stack was rebased onto current devel on 28 Oct). This adds a CI workflow that checks whether MEDUSA builds and passes beyond the single image tests.yml runs on.

What it runs

.github/workflows/platforms.yml:

job	compiler	why
Ubuntu 22.04	GCC 11, CMake 3.22, GMP 6.2.1	oldest supported: MoToBuddy needs GCC 11+
Ubuntu 24.04	GCC 13, CMake 3.28, GMP 6.3.0	what tests.yml runs on: the reference
Ubuntu 26.04	GCC 15, CMake 4.2, GMP 6.3.0	newest LTS
Ubuntu 24.04	clang	a second compiler
macOS 15, Apple Silicon	Apple clang, Homebrew GMP	ARM and the usual laptop setup

The Ubuntu jobs run in ubuntu:<release> containers on an x86_64 runner.

What each job checks

.github/scripts/platform-probe.sh goes through every leaf type (f32, f64, f80, f128, gmp). For each one it builds MEDUSA, then runs:

• the unit suite;
• the Grover matrix (amplitude-level checks, classic and --symbolic);
• the circuit smoke test.

The job summary gets a pass/FAIL table, headed by the actual compiler, CMake and GMP versions. Logs are uploaded as artifacts. A failure listed in EXPECT_FAIL doesn't fail the job, and an expected failure that starts passing raises a warning.

When it runs

Weekly, on demand (workflow_dispatch), and on PRs that touch the Makefile, src/, tests/ or the probe itself.

Results (on top of #47)

All jobs pass. On top of #48, f128 no longer needs libquadmath, so it builds and passes under clang on Linux too. The only expected failure is f128 on macOS (EXPECT_FAIL), which has no 128-bit type at all; #49 explores SoftFloat for it.

The f80 row is labelled with what long double really is. It's x87 80-bit extended only on x86. On Apple Silicon it's a plain double, so the row duplicates f64, and on ARM Linux it's binary128. Where it isn't 80-bit, the table names the real type and a note says that 80-bit precision wasn't tested, instead of a bare "pass". This came from the automated review.

Without #47, the probe found these failures:

• GMP failed to build on GCC 14+ and clang (include order; fixed on devel by 3755811);
• nothing built on macOS (-ffat-lto-objects);
• GMP failed to link on macOS (libquadmath).

Still open

• flex and bison: MoToBuddy needed them to build its bddcalc example. Upstream has fixed this (VeriFIT/MoToBuddy@acc4c26 replaces the flex/bison parser with a hand-written one). MEDUSA picked that up with the pin bump in build: bump MoToBuddy to acc4c26 (no flex/bison needed) #50 (now 3f9b6b4 on devel), so the containers here no longer install flex or bison.
• Ubuntu 20.04 was dropped: its GCC 9 can't compile MoToBuddy's declarations directly after case labels. That's still the case at acc4c26.

🤖 Generated with Claude Code

https://claude.ai/code/session_012q87VyzNBV8gtH2ntMeKoM

[github-actions]

Claude Code review (CERIT, model coder) of 35adbc7

I read pr.md and pr.diff first (both changed files — .github/scripts/platform-probe.sh and .github/workflows/platforms.yml — are shown in full; no files are omitted from the diff), then cross-checked the probe's make invocations against the Makefile (targets buddy_doubles, test-grover-f32/f64/f80/f128, buddy_gmp, test-unit-gmp, test-grover-gmp, test_unit_api, output names MEDUSA_buddy_doubles_<sfx>/MEDUSA_buddy_gmp), the test scripts it drives (tests/test_circuits.sh, tests/test_summary.sh) and the leaf headers, since the PR is CI-only and all of its behaviour lives in those two new files.

• .github/workflows/platforms.yml:51-56 (with claude-review-input/pr.md:30) - the Ubuntu clang job sets no EXPECT_FAIL, but the PR description says f128 fails under clang on Linux too and "that step is listed in EXPECT_FAIL". EXPECT_FAIL is only set in the macos job (line 97), for build-f128. The concrete failure: if build-f128 does fail under clang on Linux as the description claims was observed (the description attributes it to missing libquadmath), then on the Ubuntu 24.04, clang matrix leg the probe records build-f128 as an unexpected failure, unexpected=1, exit 1, and the job goes red — the description's "All jobs pass" and the workflow cannot both be true. Note the checkout's src/interface_implementations/leaf_primitives/leaf_primitive_double.h:90-96 instead says f128 uses glibc's *f128 functions and "Neither needs GCC's libquadmath, so clang works too", in which case the Linux clang leg builds fine and only the description is stale — I cannot build with clang here to tell which of the two is wrong, but one of them is: either add EXPECT_FAIL: build-f128 to the clang leg, or update the PR description's Results section.

I found no other issues: the probe's step naming (build-/unit-/grover-/circuits-<leaf>), the rm -f test_unit_api guard against the shared unit-binary name, the expected-fail matching (*" ${name} "* against " ${EXPECT_FAIL:-} "), the pass*-return convention used by the if step build-... guards, the summary table cell lookup, and the workflow's compiler selection (CC/CXX exported before make init, propagated to the probe's make via MAKE_ARGS and to the recursive $(MAKE) calls via MAKEFLAGS) all check out against the Makefile and test scripts.
_{Automated and advisory: it may be wrong, and it does not block merging. Run.}