https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123415
Bug ID: 123415
Summary: Several AVX512BW/DQ tests FAIL with Solaris/x86 as
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i?86-*-solaris2*, x86_64-*-solaris2*
Several AVX512BW and AVXDQ tests FAIL on Solaris/x86 when using the native as.
The failures are always due to one of two issues:
* AVX512 insns using %k0 as source or destination register. E.g.
$ cat k0.s
vpmovb2m %xmm1, %k0
$ /bin/as -m32 k0.s
Assembler:
"k0.s", line 1 : Invalid instruction argument
Near line: " vpmovb2m %xmm1, %k0"
This is due to a misunderstanding. The October 2025 edition of the Intel
SDM has
EVEX.128.F3.0F38.W0 29 /r
VPMOVB2M k1, xmm1
k1 here was taken to mean only %k1-%k7, while
3.1.1.3 Instruction Column in the Opcode Summary Table
* k1 — A mask register used as a regular operand (either destination or
source). The 64-bit k registers are: k0 through k7.
I guess this could be worked around in GCC.
* The other issue is as not accepting {sae}, e.g. in
$ cat vreduce-sae.s
vreducepd $35, {sae}, %zmm1, %zmm0
$ /bin/as -m32 -xbrace_comment=yes vreduce-sae.s
Assembler:
"vreduce-sae.s", line 1 : Syntax error
Near line: " vreducepd $35, {sae}, %zmm1, %zmm0"
This isn't accepted because the affected insns seem to always imply {sae},
to no explicit syntax was deemed necessary.
The SDM seems to support this:
EVEX.512.66.0F3A.W1 56 /r ib
VREDUCEPD zmm1 {k1}{z}, zmm2/m512/m64bcst{sae}, imm8
However, as and gas generate different code with and without {sae}:
$ cat vreduce-no-sae.s
vreducepd $35, %zmm1, %zmm0
$ gas --32 vreduce-no-sae.s -o vreduce-no-sae.o.gas
$ objdump -d vreduce-no-sae.o.gas
[...]
0: 62 f3 fd 48 56 c1 23 vreducepd $0x23,%zmm1,%zmm0
$ /bin/as -m32 -xbrace_comment=yes vreduce-no-sae.s -o vreduce-no-sae.o.as
$ objdump -d objdump -d vreduce-no-sae.o.as
[...]
0: 62 f3 fd 48 56 c1 23 vreducepd $0x23,%zmm1,%zmm0
^^
$ gas --32 vreduce-sae.s -o vreduce-sae.o.gas
$ objdump -d vreduce-sae.o.gas
[...]
0: 62 f3 fd 18 56 c1 23 vreducepd $0x23,{sae},%zmm1,%zmm0
^^
So far I've failed to determine whether or not this difference is benign or
not. If it is, GCC could be changed not to emit {sae} in those cases.
It's yet unclear if (and when) either or both issues will be fixed in as.
I wonder if it would be worth pursueing the workarounds if possible.
For the moment, I guess it's best to just disable avx512bw and avx512dg in
the testsuite when using as.
