fix: GCC 13 compilation failure on AArch64 (neonbfdot BF16 + always_inline)

[swasik]

Summary

NumKong fails to compile with GCC 13 on AArch64 (tested on AWS Graviton4 / Neoverse V2, Ubuntu 24.04). This PR fixes two independent root causes.

Bug 1 — Assembler rejects FP16 instructions in neonbfdot code

Symptom: Error: selected processor does not support 'fmov v2.8h,1.0e+0'

Root cause: All 8 neonbfdot headers use #pragma GCC target("arch=armv8.6-a+simd+bf16") — without +fp16. GCC 13's optimizer materializes BF16 constants (e.g. vreinterpretq_bf16_u16(vdupq_n_u16(0x3F80))) as fmov v.8h, 1.0, which is a FEAT_FP16 instruction. Without +fp16 in the pragma, GCC emits .arch armv8.6-a+crc in the assembly (no fp16), and the assembler rejects the fmov.

All 6 failing fmov v.8h instructions originate in nk_reduce_moments_bf16_neonbfdot but the same pattern exists in all neonbfdot headers.

Fix: armv8.6-a+simd+bf16 → armv8.6-a+simd+bf16+fp16 in all 8 neonbfdot headers (both #pragma GCC target and #pragma clang attribute push).

Affected headers

Header	Lines
include/numkong/curved/neonbfdot.h	39, 42
include/numkong/dot/neonbfdot.h	72, 75
include/numkong/dots/neonbfdot.h	22, 25
include/numkong/each/neonbfdot.h	45, 48
include/numkong/mesh/neonbfdot.h	44, 47
include/numkong/reduce/neonbfdot.h	25, 28
include/numkong/spatial/neonbfdot.h	44, 47
include/numkong/spatials/neonbfdot.h	23, 26

Bug 2 — always_inline target mismatch with user CFLAGS

Symptom: error: inlining failed — always_inline function 'nk_u1x8_popcount_' target specific option mismatch

Root cause: build.rs compiles all dispatch files with a single cc::Build that has no -march flag. NK_INTERNAL (always_inline) helpers in types.h are compiled at the TU-level baseline target. If the user (or the build environment) supplies -march=native or other CFLAGS that raise the baseline above what a #pragma GCC target region specifies, GCC refuses to inline: the callee's richer target is not a subset of the caller's restricted pragma target.

Concrete example: nk_u1x8_popcount_ (types.h:1506) is NK_INTERNAL, compiled at the TU baseline. set/neon.h:58 pushes #pragma GCC target("arch=armv8-a+simd") and calls it at line 82. With -march=native (Neoverse V2), the baseline is much richer than armv8-a+simd, so GCC refuses the inline.

Fix: In build.rs, add -march=armv8-a+simd as the explicit baseline for aarch64 builds. This matches the lowest pragma target in the library, so every pragma scope is a superset and inlining succeeds.

Testing

• Environment: GCC 13.3.0, GNU Binutils 2.42, ARM Neoverse V2 (AWS Graviton4), Ubuntu 24.04
• Before: cargo build -r fails with assembler errors on dispatch_bf16.c
• After: CC=gcc cargo build -r succeeds; binary runs correctly

Notes

• SVE BF16 headers (svebfdot.h) are not affected — they load BF16 values from memory and use svbfdot_f32 directly, never triggering the constant-materialization pattern that produces FP16 fmov instructions.
• The +fp16 addition to the Clang pragmas is for consistency; Clang does not exhibit either bug.
• The -march=armv8-a+simd flag uses flag_if_supported() so it is silently ignored on compilers that don't accept it.

[swasik]

@ashvardanian FYI: The fix for the compilation bug I met while playing on AWS r8g instance.

[ashvardanian]

Very interesting! Thanks for flagging this, @swasik!

Let me think more about the build.rs changes. We probably need a more systemic solution across all platforms and SDKs.

As for the pragmas, do we actually need FP16 features for BF16 logic? Maybe we can harden the kernels somehow to avoid incorrect code-gen?

[ashvardanian]

Assuming you are already on that machine, can you please check GCC 14 and recent Clang code-gen as well? Are they immune to this issue?

[swasik]

Clang 18 works fine without the fix. I will check GCC 14 later but I am not sure if it will be available easily on Ubuntu LTS 24.

[ashvardanian]

GCC 14 should be available from default repositories on Ubuntu 24 🤗

[swasik]

GCC 14 should be available from default repositories on Ubuntu 24 🤗

You are right - strange that it is not installed by default. I changed to GCC 14 and it compiles successfully.

[ashvardanian]

Thanks for your help, @swasik! I've split your suggestions into two separate streams, cause they are pretty independent and important enough individually. First one is merged, and the second one is on the way 🤗