GCC Patch Review Adds -mavx10v1aux for Future AMD and Intel ACE CPUs

AMD's AVX10V1AUX Patch Series for GCC Is Posted for Review​

The cover letter is titled "Add AVX10V1AUX ISA support for ACEV1 on AMD platform." It says the series implements AVX10V1AUX as documented in the ACE specification published on the x86 Ecosystem Advisory Group's website. Venkataramanan Kumar is listed as co-author on the first patch. The series has four parts:

1. Initial support for AVX10V1AUX: option handling, CPU feature detection, macros and documentation.
2. Sharing built-ins and machine-description patterns from AVX10.2 and the VNNI-INT8/INT16 extensions with AVX10V1AUX.
3. Making the AVX10.2 conversion intrinsics available under AVX10V1AUX.
4. VNNI byte and word instructions, plus more test cases.

The whole series changes 33 files, with 2,275 lines added and 210 removed. The largest new file is avx10v1auxintrin.h, a 1,328-line intrinsics header. Two new tests are added, avx10v1aux-1a.c and avx10v1aux-1b.c. Phoronix says the series is out for review on gcc-patches, and nothing on the list shows a merge decision yet.

It helps to be clear about what this kind of patch does. A compiler flag like -mavx10v1aux lets GCC emit the new instructions and exposes intrinsics that programmers can call directly. It does nothing for existing hardware. Code built to require AVX10V1AUX will only run correctly on a processor that implements it.

Where AVX10V1AUX Sits Among ACEV1, AVX10_V2_AUX and AVX10.2​

ACE comes from the x86 Ecosystem Advisory Group. Intel and AMD set up the group in late 2024, and Hardware Busters lists its later members as Broadcom, Dell, Google, HPE, HP, Lenovo, Meta, Microsoft, Oracle and Red Hat. ACE adds matrix acceleration to x86. The design builds directly on AVX-512, or more specifically AVX10, and introduces new matrix (tile) registers, with the goal of ACE operations cooperating directly with AVX-512/AVX10 operations. Heise reports that version 1.15 of the ACE specification is available from the advisory group, and that it describes the instructions rather than any concrete implementation.

The specification comes in layers, and AVX10V1AUX is the smallest of them. It is not the matrix engine itself. Phoronix describes it as the auxiliary update to AVX10.1 within the ACE initiative. In Phoronix's words it is less extensive than AVX10_V2_AUX, which carries the compressed AI data formats, but it does include "transitionary instructions that map onto the AVX10.2 structure."

AMD posted the larger AVX10_V2_AUX series in July. Phoronix wrote then that it adds onto AVX10 with instructions for converting standard data types to compressed data formats like FP4 and FP6, support for additional OCP microscaling formats, new rounding modes, and more. Sharma wrote that series as well.

Heise's summary of the specification points to why a smaller auxiliary set might be needed: processors with ACE-v1 compute units must also support a specific subset of the instruction set of AVX10.2. The patches fit that requirement. AVX10V1AUX takes AVX10.2's conversion intrinsics and VNNI patterns and puts them on an AVX10.1 base. Our reading, which is an inference and not something the patch authors say, is that AVX10V1AUX packages the AVX10.2 features ACE depends on, so a chip can support ACE without implementing all of AVX10.2.

How -mavx10v1aux Plugs Into GCC's x86 Target Code​

The first patch contains the plumbing, and the code is specific enough to show how the feature would behave.

The option's help text describes -mavx10v1aux as enabling built-ins and code generation for MMX, SSE through SSE4.2, AVX, AVX2, AVX10.1 and AVX10V1AUX. Turning it on also turns on the AVX10.1 flag set. When the flag is active, GCC defines the preprocessor macro __AVX10V1AUX__, so source code can check at compile time whether the paths are enabled. The patch also adds avx10v1aux and no-avx10v1aux to GCC's function-level target("...") attribute. That lets one function use the instructions while the rest of the program targets a more conservative baseline.

The dependencies between the flags are set up in both directions:

• Enabling -macev1 now enables AVX10V1AUX too, together with the AVX10_V2_AUX set it already pulled in.
• Disabling AVX10.1 now also disables AVX10V1AUX, and disabling AVX10V1AUX also disables ACEV1.
• AVX10V1AUX gets its own entry in GCC's ISA names table, so __builtin_cpu_supports("avx10v1aux") and function multiversioning can refer to it.

For runtime detection, the patch defines bit_AVX10V1AUX as bit 2 of ECX in the AVX10 CPUID sub-leaf (leaf 0x24, sub-leaf 1). That sits next to the existing AVX10V2AUX bit at bit 3. GCC's cpuinfo.h code sets the new feature flag when the bit is present.

The most telling change is to the ACE detection condition. Before the patch, GCC only queried the ACE leaf (0x1d) if the processor reported AVX10 version 2 or later, along with AVX10_V2_AUX and the ACE bit. A comment in the code said: "TODO: Change the condition after AVX10V1AUX is added." The patch rewrites the check so it also passes when the processor reports AVX10 version 1 plus AVX10V1AUX. AVX10_V2_AUX and the ACE bit are still required. In other words, GCC's runtime dispatcher would now accept an AVX10.1-level CPU with the auxiliary extensions as an ACE machine. The patch doesn't say which products would report that combination.

Reusing AVX10.2 Built-ins and VNNI Code Instead of Duplicating It​

Patches two to four mostly reuse existing GCC code. The file list shows large changes to i386-builtin.def (308 lines changed) and sse.md (74 lines), where GCC defines built-in functions and instruction patterns. The patch titles say AVX10.2 and VNNI-INT8/INT16 built-ins and patterns are being shared, not copied. The same instruction pattern can then be enabled under either ISA flag.

Phoronix sums up the result: the patches add the infrastructure, share built-ins and patterns from AVX10.2, VNNI-INT8 and VNNI-INT16, and carry the AVX10.2 conversion intrinsics over to AVX10V1AUX.

This has a practical effect for anyone writing intrinsics code. If AVX10V1AUX reuses AVX10.2's built-ins, the intrinsic names should stay the same. Only the ISA guard that makes them available changes. Kernels written for AVX10.2 conversion and dot-product operations could then be compiled for AVX10V1AUX targets with fewer source changes. That is our inference from the patch structure. How much overlap there is in practice depends on the 1,328-line header, and on what reviewers ask to change before a merge.

Several existing tests also changed. These are sse-12.c through sse-23.c, avx-1.c, and the C++ i386-2.C and i386-3.C, which check that all x86 intrinsic headers compile together. target-supports.exp gains an avx10v1aux predicate, so tests can be skipped on hardware that can't run the instructions.

GCC 17's ACE Support Is Arriving in Stages​

AVX10V1AUX is one step in a larger effort. According to Phoronix, Intel compiler engineers posted initial GCC compiler patches for the AI Compute Extensions in July, before AMD's AVX10_V2_AUX series. Hardware Busters later reported that the initial enablement patches for the AI Compute Extensions landed in the GCC Git tree, and that the switch is -macev1, and enabling it implicitly pulls in AVX10.1, AVX and AVX2, and the SSE/SSE4 baseline. The AVX10V1AUX patch backs this up: its code context already refers to in-tree ACEV1 and AVX10V2AUX flags, CPUID bits and feature enums.

Phoronix places the work within the push to bring ACE to GCC 17. Being part of that plan doesn't guarantee these patches get in, though. They still need maintainer review and approval before GCC 17's development window closes.

The target hardware is still unannounced. Phoronix describes -mavx10v1aux as for "capable yet-to-be-released processors from Intel and AMD," while the patch cover letter only mentions the AMD platform. Other coverage has linked ACE to AMD's future roadmap. OC3D noted AMD's promise of a "new Matrix Engine" and "AI Data Format Expansion" with Zen 7, but added that ACE support arriving with Zen 7 remains unconfirmed. No outlet has linked AVX10V1AUX specifically to a named chip.

What This Means for Developers and IT Teams​

Most people don't need to do anything yet. Nobody should change build flags until the patches are merged, appear in a released GCC, and hardware that reports the CPUID bit exists. The groups that should pay attention now are maintainers of performance-critical x86 libraries, such as AI inference runtimes, math kernels and codecs, and anyone who manages compiler toolchains or build baselines.

There's one likely Windows connection, and it is our inference, not something the patches state. The changes are in GCC's generic x86 (i386) backend, so they would apply to any x86-64 GCC build that includes them. That should cover MinGW-w64 toolchains that produce Windows binaries. The series doesn't cover MSVC or LLVM/Clang, which need their own support.

When the support does ship, the usual rules for new ISA extensions apply. A binary built with -mavx10v1aux across the whole program can crash with illegal-instruction faults on CPUs without the extension. For distributable software, the safer options are GCC's target("avx10v1aux") attribute or function multiversioning, with runtime checks through __builtin_cpu_supports.

• The AVX10V1AUX series is a four-patch proposal posted September 23, 2026. It is not in any GCC release.
• The proposed flag is -mavx10v1aux. It implies AVX10.1 and the SSE/AVX/AVX2 baseline and defines the __AVX10V1AUX__ macro.
• Runtime detection uses bit 2 of ECX in CPUID leaf 0x24, sub-leaf 1. GCC's ACE check would then also accept AVX10.1 processors that report AVX10V1AUX.
• Enabling -macev1 would also enable AVX10V1AUX, and disabling AVX10V1AUX disables ACEV1. This is worth knowing for anyone building flag matrices.
• No shipping Intel or AMD processor supports AVX10V1AUX yet. The series includes no benchmarks, so there are no performance claims to judge.
• Portable software should put AVX10V1AUX code paths behind function attributes or multiversioning and not enable the flag for the whole binary.

The series is small, but it helps explain how ACE is structured. Reading the patches together with Heise's summary of the specification suggests ACE isn't meant only for chips with full AVX10.2. A separate AVX10V1AUX feature and a relaxed CPUID check in GCC would let AVX10.1-class processors qualify too, which fits both companies' stated aim of one standard from laptops to servers. The next concrete step is maintainer review on gcc-patches. If the series is merged before GCC 17's feature freeze, library authors can write and test AVX10V1AUX code paths before the matching Intel and AMD silicon is announced.