Upgrade llama.cpp from b11632 to b11639 and install oneDNN for the Linux SYCL module

[bernardladenthin]

Summary

• Pin b11632 → b11639 (a0e6dc738, upstream master head of 2026-10-14), pinned through JLLAMA_GIT_COMMIT like b11632 -- upstream's newest tag is still b11627. 7 commits, 57 KiB, nothing in common/, include/, src/ or tools/, so no project source change. It brings the SET_ROWS work-buffer overrun fix for every CPU module (#30454), x86 FP16->FP32 back on the lookup table under F16C (#30343, the 45-65 % MUL_MAT_ID regression with clang -- the compiler of the Windows x86-64 jar), an OpenCL CLAMP fix (#30186) and SYCL IQ3 reordering (#29107).
• Linux SYCL job installs intel-oneapi-dnnl-devel. #29107 (b11636) makes oneDNN mandatory for GGML_SYCL_DNN=ON (the default): a missing or CPU-only DNNL is a configure-time FATAL_ERROR now. The shipped Linux libggml-sycl.so (snapshot) has no libdnnl in its DT_NEEDED, so build-linux-x86_64-sycl would have stopped at configure. The Windows job already installs intel.oneapi.win.dnnl; its ggml-sycl.dll imports dnnl.dll, so it is unaffected.
• patches/0019's && !defined(__F16C__) carve-out becomes load-bearing here (it was inert at b11632) and holds; CLAUDE.md and docs/history/llama-cpp-breaking-changes.md record it.

Test plan

• All twelve patches apply unchanged at a0e6dc738; check-patches.py 12 patches / 94 hunks / 0 problems
• gcc -E of the patched simd-mappings.h silent for -march=x86-64, -msse4.2, haswell, sapphirerapids, znver4, -mavx -mf16c
• Production path locally (fresh build dir, FetchContent by commit, applier, pin check fetched commit count 11639 = b11639): ctest 601/601
• Model-free native Java tests over that library (NativeLibraryLoadSmokeTest, LlamaLoggerTest, RpcServerTest, BackendLoadTest): 27/27
• check-natives, check-run-scripts, check-shared-files, check-release-gate, buildcheck unit tests (122) green
• CI: the Linux SYCL job with oneDNN (no Intel toolchain locally), the modular natives and the model-backed Java suite
• Docs updated (CLAUDE.md, README badge, history rows)

Related issues / PRs

Follows #537 (b11632). Upstream: ggml-org/llama.cpp#29107, ggml-org/llama.cpp#30343, ggml-org/llama.cpp#30454, ggml-org/llama.cpp#30186; 0019 is ggml-org/llama.cpp#30505 (still open).

Checklist

• I have read CONTRIBUTING.md and CODE_OF_CONDUCT.md
• My commits follow Conventional Commits (they follow this repo's Upgrade llama.cpp from bX to bY convention)
• No security-sensitive changes

🤖 Generated with Claude Code

https://claude.ai/code/session_01DdW3CyYtKkK6BQ3VGARo2E

---

Generated by Claude Code

[bernardladenthin]

Verify GPG signing key and Verify GPG signing key — Gradle/BouncyCastle path are red, and not because of this PR.

Both jobs run with environment: maven-central. On this PR branch they finish in 2 s without running a single step; that is the environment refusing a non-main ref before the job starts, not the signing self-test failing. The PR run of #538 (38641640688, branch local/arm-fp16-rebase) shows exactly the same, and on main (dispatch 38218935644) both jobs run all their steps and pass. The diff here touches neither the jobs nor verify-signing-key.sh.

So there is no fix to port. It is the repository's environment protection, which gates the publish jobs and not this PR, and changing it is a settings decision for the maintainer. A re-run would fail the same way, so I am not spending one. Everything else in the pipeline is still waiting on the startgate environment.

---

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