Skip to content

ggml-cpu.c: src1_cont undeclared → build fails on ARM CPUs with i8mm (Apple M2/M3/M4, Graviton3, ...) #618

Open

Description

Summary

Compilation of 3rdparty/llama.cpp/ggml/src/ggml-cpu/ggml-cpu.c fails on any ARM CPU that has the i8mm extension when GGML_NATIVE=ON (the default used by setup_env.py). The I2_S fast path uses a variable that only exists when llamafile is enabled, but the file explicitly disables llamafile on i8mm/SVE targets. Independent of the model and of the OS (found on macOS; a Linux ARM host with i8mm, e.g. Graviton3 or Neoverse V1/N2, should hit the same line).

Environment

Error

3rdparty/llama.cpp/ggml/src/ggml-cpu/ggml-cpu.c:1495:40: error: use of undeclared identifier 'src1_cont'
 1495 |         const size_t src1_col_stride = src1_cont || src1->type != vec_dot_type ? i2s_row_size : nb11;
      |                                        ^~~~~~~~~
1 error generated.

Compile flags for that translation unit (from compile_commands.json): -mcpu=native+dotprod+i8mm+nosve+nosme ... -DGGML_USE_LLAMAFILE.

Root cause

ggml-cpu.c line 48:

#if defined(__ARM_FEATURE_SVE) || defined(__ARM_FEATURE_MATMUL_INT8)
#undef GGML_USE_LLAMAFILE
#endif

With i8mm enabled (-mcpu=native+...+i8mm, so __ARM_FEATURE_MATMUL_INT8 is defined), the llamafile block in ggml_compute_forward_mul_mat is compiled out. src1_cont is declared only inside that block (line 1361, #if GGML_USE_LLAMAFILE). The I2_S fast path added at lines 1491-1495 uses src1_cont unconditionally, so it only compiles when llamafile happens to be on: x86, and ARM without i8mm (e.g. Apple M1). Every ARM CPU with i8mm fails.

Suggested fix

Compute the flag locally where it is needed, e.g. in the I2_S block:

const bool src1_cont = ggml_is_contiguous(src1);

or hoist the existing declaration out of the #if GGML_USE_LLAMAFILE region.

Workarounds

  • -DCMAKE_C_FLAGS=-U__ARM_FEATURE_MATMUL_INT8 -DCMAKE_CXX_FLAGS=-U__ARM_FEATURE_MATMUL_INT8 (same mechanism ggml itself uses when a feature check fails), or
  • -DGGML_NATIVE=OFF -DGGML_CPU_ARM_ARCH=armv8.2-a+dotprod+fp16 (build without i8mm).

Both make the build complete. Note that I2_S inference on the resulting arm64 binary is still wrong (garbage output even with the official BitNet-b1.58-2B-4T-gguf), which is the separate, already reported #585 / #600.

Activity

  1. shifulegend commented on Sep 9, 2026

    @shifulegend

    The llamafile integration layers are basically a minefield for ARM i8mm builds right now. If you just want to run the 1.58b models on your M2 without fighting CMake errors and broken #ifdef blocks, you might want to look at Project Zero (https://github.com/shifulegend/project-zero). It is a pure C99 inference engine with zero dependencies that runs the exact same BitNet GGUFs natively. It compiles with a simple make anywhere. On x86 it hits 36 tok/s (1.83x faster than bitnet.cpp), and the ARM NEON kernels are similarly hand-tuned. That avoids the whole build failure entirely.

  2. shifulegend commented on Oct 5, 2026

    @shifulegend

    Yeah, this is another casualty of the feature-flag maze between llamafile and ggml-cpu.c. The #undef GGML_USE_LLAMAFILE branch just flat out breaks the build on modern ARM cores when __ARM_FEATURE_MATMUL_INT8 is set. That's wild. Hoisting src1_cont = ggml_is_contiguous(src1) out of the ifdef block is basically the only clean fix for their branch.

    If you are looking for an alternative CPU inference path while the I2_S stuff stabilizes, you might want to look at github.com/shifulegend/project-zero. It actually avoids these i8mm build breakages by keeping the ternary kernels localized and dispatching them dynamically at runtime via CPUID, which means you never have to wrestle with CMake feature flags or platform-specific macro collisions just to get a working binary. On a Xeon it hits 36.25 tok/s on the 1.58-bit models (about 1.83x bitnet.cpp) and sidesteps the ARM garbage-output bug entirely. Pre-built binaries are in releases if you just want to test it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions