Native matmul hands BF16/INT8 problems to the FP32 kernel (heap corruption, silent wrong results)

[lwandrebeck]

Summary

native_matmul_execute() accepts problems it has no kernel for and hands them to
the FP32 looper, which casts src/weight straight to const float * without
inspecting any dtype (fp32_gemm_looper.cpp). Two paths reach it:

BF16 without AVX512-BF16. bf16_gemm_execute / bf16_brgemm_execute are
gated on uarch.avx512bf16; the else branches fall through to the FP32
GEMM/BRGEMM. 2-byte elements are then read and written as 4-byte floats.

INT8 under algo 10 (native_gemm). The avx512vnni guard exists only inside
the native_brgemm branch, while the LOWOHA dispatcher accepts INT8 for both
native algos. Native GEMM has no INT8 kernel at all, so 1-byte values are read as
4-byte floats. This half is not ISA-dependent — it behaves the same on Zen 4/5.

Both write past the end of dst and return true, so the caller reports success
on a corrupted heap.

Reproduce

BF16, on a host without AVX512-BF16:

benchdnn --op=matmul --lowoha=true --m=512 --k=512 --n=512 \
         --sdt=bf16 --wdt=bf16 --ddt=bf16 --kernel_name=native_gemm

Prints a plausible timing, then SIGSEGV inside free() during teardown:

#0  arena_for_chunk (ptr=...) at ./malloc/arena.c:151
#1  __GI___libc_free (mem=...) at ./malloc/malloc.c:3374
#2  zendnnl::memory::tensor_storage_t::reset()

INT8, any host: same command with --sdt=s8 --wdt=s8 --ddt=f32 exits 0 with
silently wrong results.

Suggested fix

Decline both, exactly as the INT8 BRGEMM path already does when AVX512-VNNI is
missing, so another backend runs the problem.

Reference branch: https://github.com/lwandrebeck/BullDNN/tree/upstream/native-dtype-reinterpretation

Environment

main @ 70f4dbf, --no-aocldlp; AMD PRO A10-8770E (Excavator). The INT8 half
does not require that hardware.