Re: [PATCH] x86: rename avx10.1aux to avx10v1aux

On 19.08.2026 10:18, Rohan Shenoy wrote:
> Align with GCC/Clang naming (-mavx10v2aux) as discussed [1].

This could do with a little bit more of an explanation. I don't quite see how
compiler command line options and assembler directive operands are in direct
need to be fully in sync.

> ---
>  gas/config/tc-i386.c                                      | 2 +-
>  gas/doc/c-i386.texi                                       | 4 ++--
>  .../i386/{avx10.1-aux-256-cvt.d => avx10v1aux-256-cvt.d}  | 0
>  .../i386/{avx10.1-aux-256-cvt.s => avx10v1aux-256-cvt.s}  | 2 +-
>  .../{avx10.1-aux-256-media.l => avx10v1aux-256-media.l}   | 0
>  .../{avx10.1-aux-256-media.s => avx10v1aux-256-media.s}   | 2 +-
>  .../i386/{avx10.1-aux-512-cvt.d => avx10v1aux-512-cvt.d}  | 0
>  .../i386/{avx10.1-aux-512-cvt.s => avx10v1aux-512-cvt.s}  | 2 +-
>  .../{avx10.1-aux-512-media.l => avx10v1aux-512-media.l}   | 0
>  .../{avx10.1-aux-512-media.s => avx10v1aux-512-media.s}   | 2 +-
>  gas/testsuite/gas/i386/i386.exp                           | 8 ++++----
>  11 files changed, 11 insertions(+), 11 deletions(-)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-256-cvt.d => avx10v1aux-256-cvt.d} (100%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-256-cvt.s => avx10v1aux-256-cvt.s} (84%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-256-media.l => avx10v1aux-256-media.l} (100%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-256-media.s => avx10v1aux-256-media.s} (84%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-512-cvt.d => avx10v1aux-512-cvt.d} (100%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-512-cvt.s => avx10v1aux-512-cvt.s} (84%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-512-media.l => avx10v1aux-512-media.l} (100%)
>  rename gas/testsuite/gas/i386/{avx10.1-aux-512-media.s => avx10v1aux-512-media.s} (84%)

I may not want to veto these renames, but I certainly don't view them as useful.

> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -1253,7 +1253,7 @@ static const arch_entry cpu_arch[] =
>    VECARCH (sm4, SM4, ANY_SM4, reset),
>    SUBARCH (pbndkb, PBNDKB, PBNDKB, false),
>    VECARCH (avx10.1, AVX10_1, ANY_AVX512F, set),
> -  VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
> +  VECARCH (avx10v1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
>    VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),

So what about the avx10.1 and avx10.2 operands then? Are we meaning to become
inconsistent just because Clang and later maybe gcc are? In both I see -mavx10.1
and -mavx10.2. How does that fit with -mavx10v2aux (which Clang trunk, as
available on godbolt.org, doesn't even recognize yet, as opposed to gcc trunk)?
As that's still under development, may I suggest that instead Clang / gcc
reconsider the naming used?

If they don't want to switch to consistent naming, my next best suggestion for
gas would then be to recognize both avx10.1aux and avx10v1aux (and subsequently
similarly for v2-aux).

Jan