Skip to content

feat!: upgrade llama.cpp from b10797 to b10817 - #415

Merged
bernardladenthin merged 1 commit into
mainfrom
claude/llama-cpp-b10817
Sep 5, 2026
Merged

feat!: upgrade llama.cpp from b10797 to b10817#415
bernardladenthin merged 1 commit into
mainfrom
claude/llama-cpp-b10817

Conversation

@bernardladenthin

Copy link
Copy Markdown
Owner

Summary

No project-source change. The whole review surface across the paths this project links against is 7 files, +12 / −13; everything else in the 20-commit range is GPU-backend work (ggml-opencl +940 lines and a new 871-line Adreno SDPA kernel, Metal fa-vec tunings for M3/M3 Max, SYCL memtrace), a new model architecture (src/models/hy-v4.cpp), upstream CI and the WebUI.

Two entries needed checking rather than skimming:

  • common/build-info.hllama_print_build_info(const char *) became llama_print_build_info(const char *, FILE * = stderr) (#28322). A default argument, so every existing one-argument call still compiles; the project does not call it at all and reads llama_build_info(), which is untouched. Worth flagging anyway, because build-info is exactly what NativeLibraryLoadSmokeTest cross-checks against the pin — and this is the second consecutive range to move that file (b10792→b10797 carried #28278).
  • ggml/include/ggml-backend.h REMOVES ggml_backend_op_alloc_size_may_expand (via the #28379 ggml sync). A deletion from a public header is the one shape that breaks a build with no diff hunk to notice, so the project source was grepped for it: zero references, in src/main/cpp and src/test/cpp alike.

The server contract was re-checked mechanically and is byte-identical (request fields, set_hard_limits bounds, response keys in both emit forms) — tools/server/ has no .cpp/.h change in the range at all. mtmd.cpp/clip.cpp change gemma4 vision handling and an image-token limit inside upstream translation units, with no API movement. The remaining three files are upstream's own version bump and a BoringSSL pin that only applies with LLAMA_BUILD_BORINGSSL, which this project leaves off.

Patches: zero intersection with the 42 files the eight patches touch, so no context can have moved. The applier was run for real anyway — fresh build dir, configure clean, stamp at head cd8cdf39, all eight hashes recorded.

Chunking: the full diff is 307 KB, over the runbook's 100 KiB threshold, but excluding ggml/src, tools/ui, docs, .github and conversion — every one outside the review surface the rule exists to bound — it is 68 KB, under it. Same call as the previous bump, and here the excluded-diff figure alone justifies it. Recorded in docs/history/ so the deviation stays auditable.

⚠️ This does NOT fix the macOS 15 regression

src/llama-model-loader.cpp is untouched in this range and hparams.n_expert_used_max() — the prime suspect from #28323, introduced at b10797 — is still called at both sites. Expect Java Tests macOS 15 arm64 (Metal) and (no Metal) to stay red. The bisect I proposed in #414 is still the open item; say the word and I'll push a probe branch pinned back to b10792.

Test plan

  • Fresh rm -rf build && cmake -B build -DBUILD_TESTING=ON — the fail-loud PATCH_COMMAND ran for real; stamp cd8cdf397dc21d986e69069ce2180651d693fdff
  • Full native build, zero warnings on the project TUs
  • ctest 520/520
  • mvn clean verify1486 Java tests, 0 failures
  • .github/verify-bytecode-version.sh --max-major 52 llama/target clean
  • CI is green on this branch — macOS 15 is expected to stay red, see above
  • Docs updated — four pin files, a folded b10731 → b10817 CHANGELOG entry, two new rows in docs/history/llama-cpp-breaking-changes.md

A note on the verification, because it is the reason this is trustworthy rather than assumed: my first mvn clean verify on this branch failed, because a repo-wide git reset --hard I ran for an unrelated dependency audit had silently discarded the uncommitted pin edits while the native library was already built at b10817. NativeLibraryLoadSmokeTest.nativeBuildInfoMatchesPinnedVersionConstant caught exactly that drift and named it precisely (Linked build-info "b10817-cd8cdf397" must start with the pinned tag "b10797-"). The edits were restored and the full gate re-run green. The guard works.

Checklist

  • I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
  • My commits follow Conventional Commits
  • No security-sensitive changes

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH


Generated by Claude Code

No project-source change. The whole review surface across the paths this
project links against is 7 files, +12/-13; everything else in the 20-commit
range is GPU-backend work (ggml-opencl +940 lines and a new 871-line Adreno
SDPA kernel, Metal fa-vec tunings for M3/M3 Max, SYCL memtrace), a new model
architecture (src/models/hy-v4.cpp), upstream CI and the WebUI.

Two entries needed checking rather than skimming:

  * common/build-info.h: llama_print_build_info(const char *) became
    llama_print_build_info(const char *, FILE * = stderr) (#28322). A DEFAULT
    argument, so every existing one-argument call still compiles; the project
    does not call it at all and reads llama_build_info(), which is untouched.
    Worth noting anyway because build-info is exactly what
    NativeLibraryLoadSmokeTest cross-checks against the pin, and this is the
    second consecutive range to move that file (b10792->b10797 carried #28278).
  * ggml/include/ggml-backend.h REMOVES ggml_backend_op_alloc_size_may_expand
    (via the #28379 ggml sync). A deletion from a public header is the one shape
    that breaks a build with no diff hunk to notice, so the project source was
    grepped for it: zero references, in src/main/cpp and src/test/cpp alike.

The server contract was re-checked mechanically and is byte-identical (request
fields, set_hard_limits bounds, response keys in both emit forms) -- tools/server
has no .cpp/.h change in the range at all. mtmd.cpp/clip.cpp change gemma4 vision
handling and an image-token limit inside upstream translation units, with no API
movement. The remaining three files are upstream's own version bump and a
BoringSSL pin that only applies with LLAMA_BUILD_BORINGSSL, which this project
leaves off.

Patches: zero intersection with the 42 files the eight patches touch, so no
context can have moved. The applier was run for real anyway -- fresh build dir,
configure clean, stamp at head cd8cdf39, all eight hashes recorded.

Chunking: the full diff is 307 KB, over the runbook's 100 KiB threshold, but
excluding ggml/src, tools/ui, docs, .github and conversion -- every one outside
the review surface the rule exists to bound -- it is 68 KB, under it. Same call
as the previous bump, and here the excluded-diff figure alone justifies it.

This range does NOT address the macOS-15 regression introduced at b10797:
src/llama-model-loader.cpp is untouched here and hparams.n_expert_used_max()
(the prime suspect from #28323) is still called at both sites. Expect
`Java Tests macOS 15 arm64` to stay red until that is bisected.

Verified locally: fresh configure clean, full build with zero warnings on the
project TUs, ctest 520/520, mvn clean verify 1486 Java tests green (including
NativeLibraryLoadSmokeTest, which cross-checks LLAMA_CPP_VERSION against the
linked build-info), bytecode gate clean over llama/target.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH
@claude

claude Bot commented Sep 5, 2026

Copy link
Copy Markdown

Code Review Summary ✅

Version pins are consistent and correct:

  • CMakeLists.txt: GIT_TAG b10817
  • LlamaCppVersion.java: LLAMA_CPP_VERSION = "b10817"
  • README.md: Badge updated
  • CLAUDE.md: All 4 references updated
  • CHANGELOG.md: Detailed documentation
  • docs/history: Two comprehensive rows added

Verification Quality ⭐

  • 520/520 C++ tests passing
  • 1486 Java tests passing
  • Patch applier verified on fresh build
  • Bytecode gate clean
  • Server contract byte-verified
  • API removals checked (zero refs)

API Compatibility ✅

  • common/build-info.h: llama_print_build_info() gains optional FILE * (backward compatible)
  • ggml/include/ggml-backend.h: ggml_backend_op_alloc_size_may_expand removed (zero refs in project)

Known Limitations

  • macOS-15 regression from b10797 correctly documented as unresolved

Recommendation: APPROVED — Thoroughly verified and well-documented. Ready for merge.

@sonarqubecloud

sonarqubecloud Bot commented Sep 5, 2026

Copy link
Copy Markdown

@bernardladenthin
bernardladenthin merged commit 61bb0e6 into main Sep 5, 2026
13 of 17 checks passed
@bernardladenthin
bernardladenthin deleted the claude/llama-cpp-b10817 branch September 5, 2026 10:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants