Re: [PATCH v2] x86: recognize both avx10.1aux and avx10v1aux

Jan Beulich <[email protected]>
Newsgroups gmane.comp.gnu.binutils
Message-ID <[email protected]>
On 20.08.2026 09:05, Rohan Shenoy wrote:
> Accept both as names for the same feature. Keep existing naming 
> (avx10.1aux) while adding avx10v1aux, as the latter aligns with
> gcc (and Clang eventually).
> 
> gas/
> 	* config/tc-i386.c: Recognize avx10v1aux as an alias of avx10.1aux.
> 	* doc/c-i386.texi: Document avx10v1aux alongside avx10.1aux.
> 	* testsuite/gas/i386/i386.exp: Update test names accordingly.
> 	* testsuite/gas/i386/avx10v1aux-*: Rename from testsuite/gas/i386/avx10.1-aux-*.
> ---
> 
> Notes:
>     Changes in v2:
>     - Adds avx10v1aux rather than replacing avx10.1aux as per Jan's 
>     suggestion [1].
>     - Update two of the four tests (256-cvt, 512-media) to use arch 
>     avx10.1aux, so that both names are used.

This is fine, yet ...

>  gas/config/tc-i386.c                                      | 1 +
>  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}  | 0
>  .../{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}   | 0
>  gas/testsuite/gas/i386/i386.exp                           | 8 ++++----
>  11 files changed, 10 insertions(+), 7 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} (100%)
>  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} (100%)

... do you really mean to insist on this renaming? The respective ChangeLog
entry saying "Update test names accordingly" is stale, now that both forms
are recognized.

> --- a/gas/config/tc-i386.c
> +++ b/gas/config/tc-i386.c
> @@ -1253,6 +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 (avx10v1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
>    VECARCH (avx10.1aux, AVX10_1_AUX, ANY_AVX10_1_AUX, set),
>    VECARCH (avx10.2, AVX10_2, ANY_AVX10_2, set),
>    SUBARCH (user_msr, USER_MSR, USER_MSR, false),

Please insert after the existing entry, ...

> --- a/gas/doc/c-i386.texi
> +++ b/gas/doc/c-i386.texi
> @@ -221,6 +221,7 @@ accept various extension mnemonics.  For example,
>  @code{avx10.1/256},
>  @code{avx10.1/128},
>  @code{avx10.1aux},
> +@code{avx10v1aux},

... like you do here.

> @@ -1719,7 +1720,8 @@ supported on the CPU specified.  The choices for @var{cpu_type} are:
>  @item @samp{.avx512_vpopcntdq} @tab @samp{.avx512_vbmi2} @tab @samp{.avx512_vnni}
>  @item @samp{.avx512_bitalg} @tab @samp{.avx512_bf16} @tab @samp{.avx512_vp2intersect}
>  @item @samp{.tdx} @tab @samp{.avx_vnni} @tab @samp{.avx512_fp16} @tab @samp{avx512_bmm}
> -@item @samp{.avx10.1} @tab @samp{.avx10.1aux} @tab @samp{.avx10.2} @tab @samp{.clwb}
> +@item @samp{.avx10.1} @tab @samp{.avx10v1aux} @tab @samp{.avx10.1aux} @tab @samp{.avx10.2}

Similarly please swap new and old entries here.

Jan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.