feat: upgrade llama.cpp from b10903 to b10905

[bernardladenthin]

Summary

Bumps the pinned llama.cpp version from b10903 to b10905 across all four pin sites, and appends the upgrade range to the breaking-changes history.

Two commits, five files, 8 KiB — none of it on this project's review surface.

Upstream commit	What it is	Reaches us how
#28102	CUDA/HIP Flash Attention tuning for gfx1201 — ggml-cuda/fattn-common.cuh, fattn-mma-f16.cuh, fattn.cu, plus a tests/test-backend-ops.cpp case	the CUDA + HIP classifier jobs (gfx1201 is RDNA4, so the rocm-* ones are where it matters), all build-only on GPU-less runners. The test file is never compiled here — a FetchContent subproject sets LLAMA_BUILD_TESTS=OFF.
#28708	keys upstream's sanitizer CI cache per matrix entry (.github/workflows/server-sanitize.yml)	not at all — upstream's own CI

Zero files under common/, include/, tools/server/, tools/mtmd/ or src/, so every row of the API-compatibility table is vacuously satisfied and the three mechanical tools/server/ contract greps have no input. Third bump running with that property. Far under the 100 KiB threshold, so no chunking question arises. The default JAR and every CPU classifier are unaffected.

Patches: all ten apply untouched

Every patch-target file is byte-unchanged in the range — verified by diffing those paths explicitly (common/arg.{cpp,h}, common/peg-parser.cpp, all of tools/server/, src/llama-model.{cpp,h}, tests/CMakeLists.txt, ggml/src/ggml-cpu/arch/s390/) rather than inferring it from the aggregate.

This is the first bump with four standing drop-checks rather than three, since 0013 joined the set. All four were run against the pristine tag, because the fail-loud applier detects "does not apply" but never "upstream already fixed this":

Patch	Check	Result at b10905
0001	common_params_parse_main in common/arg.h	0 occurrences; WIN32 override still at common/arg.cpp:1282 → still required
0010	{"vocab_type", meta.model_vocab_type}	still uncast at server-context.cpp:4554 → still required
0012	split_sum zero guard in src/llama-model.cpp	still a bare splits[i] /= split_sum; at line 1491 → still required
0013	the three s390x VXE helpers	vxe_dot_acc / vxe_splat_granule / vxe_fold still at file scope (73/77/83) between the guards at 28–70 and 100–155 → still required

On 0013 specifically: upstream master at the time of this bump (a2878d30d) carries that file byte-identical to b10905, so the defect is live there too. It was reported on #28667, the PR that introduced it.

Test plan

• Tested locally
• Added/updated tests — no new tests; this is a pin bump. The existing guards are the test plan.
• CI passes

Verified locally on Linux x86_64 from a fresh configure (build directory removed first, so the applier took its clean-tree path and wrote a fresh stamp):

• Patch applier — stamp at head 16378d93f94012d4228c8c7683adce3f286aee5d (= b10905) with all ten SHA-256 lines; no "does not apply cleanly" abort.
• Build — full cmake --build --config Release, zero errors.
• C++ unit suite — ctest: 537/537.
• Wire-name extraction — unchanged at 138 CLI / 57 request / 15 trainer names (the configure-time OAI_LAYER reader sweep re-ran against b10905's sources).
• 0013 re-verified with the real cross toolchain. It has no runnable guard beyond the s390x CI job — unlike 0012 (test_model_split.cpp) or 0011 (ContentOnlyParseUtf8) — so the bump routine now includes it: s390x-linux-gnu-g++ compiles the applier's repack.cpp clean both with the job's own (scalar) flags and with -mvx -mzvector -march=z15. This is recorded in the history row so it does not stay tribal knowledge.
• JNI surface — nm -D: 40 Java_* exports, 0 C++-mangled.
• NativeLibraryLoadSmokeTest — 4/4, 0 skipped, run with a clean first so nativeBuildInfoMatchesPinnedVersionConstant compared the rebuilt binary against the new constant rather than a stale class.
• Full Java suite — mvn test: 1755 run, 0 failures, 0 errors (269 skipped — the model-gated classes; no GGUF in this sandbox).
• Gates — SpotBugs 0 findings; spotless:check clean (243 files); javadoc:jar BUILD SUCCESS.

Related issues

None.

Checklist

• Code follows project style (mvn spotless:apply run for Java changes) — no .java formatting changes; the one Java file touched is a constant plus javadoc.
• Documentation updated — README.md badge/link, CLAUDE.md pinned-version line (plus three incidental version mentions: the WebUI local-build recipe, the sccache section, the FetchContent source-tree section), and a new b10903–b10905 pair of rows in docs/history/llama-cpp-breaking-changes.md.
• No breaking changes — none to this project's API, and no upstream API surface this project consumes moved at all.

Files changed (5)

File	Change
llama/CMakeLists.txt	GIT_TAG b10903 → b10905
llama/src/main/java/net/ladenthin/llama/value/LlamaCppVersion.java	LLAMA_CPP_VERSION constant + 3 javadoc mentions
README.md	badge + link
CLAUDE.md	pinned-version line + 3 incidental mentions
docs/history/llama-cpp-breaking-changes.md	two appended rows

CHANGELOG.md is deliberately untouched: it records consumer-visible behaviour, and llama.cpp pin bumps are not recorded there.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud