Allow the C910V target to build with upstream GCC

[hugomeiland]

Summary

• Build TARGET=C910V with upstream GCC 14+ (-march=rv64gc_xtheadvector -mabi=lp64d) as well as the existing Xuantie toolchain. A compile probe keeps the current Xuantie march string and -mtune=c920 when xtheadvector is rejected, so the C910V CI path is unchanged.
• The C910 GEMM kernels still use unprefixed RVV 0.7 mnemonics. On upstream GCC those are wrapped as th.* via gas macros in kernel/riscv64/c910v_asm.h. The macros are empty on the Xuantie toolchain.
• dsdot_vector.c called the raw 0.7 intrinsic names. Those calls now go through RISCV_RVV(), matching the other C910 vector kernels. The reduction keeps the 4-argument 0.7 form under RISCV_0p10_INTRINSICS and the 3-argument form otherwise.

The C910 vector unit implements T-Head's draft xtheadvector extension, which has a known security issue (GhostWrite, CVE-2024-44067). Kernels that include the published mitigation disable that extension, so these kernels only run where xtheadvector is still exposed. This pull request does not change that. It only makes the existing C910V kernels buildable with upstream GCC.

TARGET=C910V is still required. Autodetection looks for a model name containing T-HEAD C910, which some boards do not provide.

Test plan

• BeagleV-Ahead (TH1520, 4× C910), GCC 14.3.0, stock OpenBLAS 0.3.34 plus this patch, make TARGET=C910V. Configured as CORE=C910V with -march=rv64gc_xtheadvector. The SGEMM kernel contains th.vsetvli.
• Official CBLAS Level 1, 2, and 3 (OPENBLAS_NUM_THREADS=2) completed with no failures. Level 2 and Level 3 inputs stop on the first failure; each driver reached END OF TESTS.
• Xuantie GCC / existing C910V CI job (probe should keep the old march string; not re-run here).

Made with Cursor