mudler / mudler/vllm.cpp

The EXL3 device arm labels never print: MESSAGE stringifies a const char* as a bool

Open Beginner friendly
#2,587 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
423
Forks
53
Avg merge
20h 26m
Merged PRs (30d)
310

Description

Row: QUANT-EXL3-MUL1

tests/vt/test_exl3_gemm.cpp's "the widened (bits, codebook) arms agree with the CPU arm" case logs each row as

MESSAGE("bits ", arm.bits, " cb ", arm.codebook, " (", arm.what,
        "): device vs CPU rel_rms = ", rel);

arm.what is a const char*, and doctest's stringifier resolves that to bool. Measured on dgx:gpu0 on 2026-09-02, every row prints (1):

MESSAGE: bits 3 cb 0 (1): device vs CPU rel_rms = 3.02751e-07
MESSAGE: bits 3 cb 2 (1): device vs CPU rel_rms = 3.02544e-07
MESSAGE: bits 6 cb 2 (1): device vs CPU rel_rms = 2.98355e-07

So the description of each arm -- which checkpoint it belongs to and how many tensors it covers -- is carried in the source and reaches nobody. The same shape is in tests/vt/test_exl3_rocm.cpp and tests/vt/test_exl3_vulkan.cpp, whose arm tables have the same const char* field.

Cosmetic: no assertion depends on it, and CAPTURE(arm.bits) / CAPTURE(arm.codebook) still identify a failing row, which is how #2574's M2 mutation was read (arm.bits := 3 arm.codebook := 2).

Fix

Wrap in std::string(arm.what) at the call, or give the table a std::string field. One line per site.

Why it is filed rather than fixed in the flow that found it

Found while gating #2574's (3, 2) arm. tests/vt/test_exl3_gemm.cpp is one of the two translation units that row's device evidence was measured on, under a git archive tarball pinned by sha256 inside the lease job. Editing it now would put the measured tree and the branch head out of step, for a change that alters no assertion. The lease queued for nearly four hours, so re-measuring to land a message format is not a good trade.

Listed under ## Owed in .agents/specs/quant-exl3-mul1.md.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the MESSAGE call in tests/vt/test_exl3_gemm.cpp and compare the arm.what field with the corresponding tables in tests/vt/test_exl3_rocm.cpp and tests/vt/test_exl3_vulkan.cpp. Check the doctest stringification behavior, then update each named site so the arm description is printed as text. Done means the EXL3 rows show their checkpoint and tensor coverage instead of (1), without changing assertions.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
testing-qa
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
88/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.