Remove all test cases that expect spmzr_el0 to be readable, and remove
some redundant default macro values from armv9_5-a-sysregs.s while we're
there.
Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be
the first test for the "reading from a write-only register" note.
Also remove the recently added -menable-sysreg-checking option from this
test, both to simplify the addition of spmzr_el0 to the test, and to
verify that read/write diagnostics don't depend on that option.
The flag is unnecessary, because we can just unconditionally check the
features field every time. Having the information duplicated in two
separate fields makes it harder to maintain, particularly in the context
of the upcoming regating patch.
The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now
unused, so remove that as well.
The opcode D6 has been officially reserved as a single-byte permanent
undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is
already the behavior of all known 64-bit implementations; this is thus
merely an official statement of forward compatibility and the
assignment of a mnemonic.
This will be documented in the next version of the Intel Software
Developer's Manual; in the meantime I DO speak officially for Intel on
this issue.
The x86 Advisory Council has ratified this decision, and so it is
expected to be honored across vendors, but I obviously cannot make any
official statement on any other vendor's behalf.
I am covered by the Intel-FSF copyright assignment for binutils.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
I made a stupid mistake in the commit 28520d7, allow to assemble slli/srli/srai
with 0 immediate to hint c.slli/c.srli/c.srai. These hints will be regared as
illegal instruction for gdb and qemu, so at least I got following gcc testcases
failed,
=== g++: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
=== gfortran: Unexpected fails for rv64gc lp64d medlow ===
FAIL: gfortran.dg/leadz_trailz_2.f90 -O0 execution test
=== gcc: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
So we should just allow c.slli/c.srli/c.srai with zero immediate as hints, but
don't allow slli/srli/srai with zero immediate.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Only allow c.slli/c.srli/c.srai
with zero immediate as hints, but don't allow slli/srli/srai with
zero immediate.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
opcodes/
PR 33216
* riscv-opc.c (match_slli_as_c_slli): Added back.
(match_srxi_as_c_srxi): Likewise.
(riscv_opcodes): Only allow c.slli/c.srli/c.srai with zero immediate
as hints, but don't allow slli/srli/srai with zero immediate.
The original patch,
e6f372ba66
Since recently c.slli64, c.srai64, and c.srli64 have been removed from the
riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed
as hints,
https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093
So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to
assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai
when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as
aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with
0 immediate.
Passed rv32/64-elf/linux binutils testcases.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64,
c.srai64, and c.srli64 with 0 immediate as a hint.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/zca.d: Likewise.
opcodes/
PR 33216
* riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64,
and c.srli64 with 0 immediate as a hint.
With the tables no longer being part of libopcodes (but rather being
compiled directly into gas), this table doesn't need exposing anymore.
The declaration cannot be avoided, though, as the first use of the
array sits ahead of its definition (in i386-tbl.h).
There's no reason to allow the array to be modifiable. In fact the
compiler is able to infer this, placing the array in .data.rel.ro, but
let's make it explicit.
Merge them into a single array of struct type. There's further no reason
to have the compiler materialize such objects on the stack. And there's
also no reason to allow the array(s) to be modifiable. Finally, given
how short the strings are, there's little point using more space to
store pointers to them (on 64-bit hosts; the situation is a little
better on 32-bit ones).
While there also correct indentation in adjacent code, and avoid open-
coding ARRAY_SIZE().
The indices into the auto-generated tables for opcodes are relatively
unstable. Adding a new opcode can permute the code significantly.
But most of this churn is down to changes in the index values. To
minimize this use enumerated constants. While the index values
change, the enumeration names will need to do so far less often, so
most of the changes in the generated code become localized to the
addition (occasionally removal) of opcodes. This change also makes
the state-change comments unnecessary. The enumeration names contain
the same information (and more), so these are simply deleted.
The enumeration values are placed in a new header file, aarch64-tbl-2.h,
so aarch64-gen gains a new option to build this header and the Makefile
rules are adjusted accordingly.
The generated aarch64 operand tables use index values into an array. But if
the table of operands is modified by inserting a new operand into the middle
of the table, *all* the index values can change, leading to a lot of
churn in the generated output.
include/opcode/aarch64.h already provides an enumeration for the operands,
so make use of that instead of printing out the raw index values.
This field was misnamed in aarch64_opcode_table. It previously didn't
matter too much as the name field only appeared in dumps. But it
doesn't match the enum in include/opcode/aarch64.h and we will shortly
start to rely on that.
In ISE058, the AVX10.2 imply is removed from AMX-AVX512. This
leads to re-consideration on the imply for AMX-AVX512.
Since it is using zmm register and using zmm register only, we
need to at least imply AVX512F. AVX512VL is not needed since it
is not using xmm/ymms.
On the other hand, if we imply AVX10.1 for AMX-AVX512, disabling
avx10.1 will lead to disabling AMX-AVX512. This would be a surprise
for users.
Based on the two reasons above, the patch is decoupling AMX-AVX512
from AVX10.2 and imply AVX512F.
opcodes/ChangeLog:
* i386-gen.c: Imply AVX512F instead of AVX10.2.
* i386-init.h: Regenerated.
By default, NIL qualifiers are treated as matching any qualifier when
checking operand constraints. For many SVE instructions, this would
allow operands with missing type suffixes to be assembled as if they had
any explicit type specified. To prevent this, the F_STRICT flag is used
to specify that NIL qualifiers should match only NIL qualifiers.
Unfortunately, several SVE instructions incorrectly omitted this
F_STRICT flag. The bug has existed in the *MATMUL_SVE* macros since
they were added in 2019. The macro LUT_SVE2_INSN was added last year,
and the other incorrect macros are new in this release.
LUTv2_SME2_INSN and LUTv2_SME2p1_INSN were not actually broken, because
we reject untyped vector lists already during parsing. However, I have
added the F_STRICT flag here anyway, since this is more consistent and
would be more robust if those operands start accepting untyped vector
lists in the future. The new luti4 tests are the only ones that were
already rejected before this change.
BFLOAT16_SVE_INSN has been unused since it was originally added, so I
just deleted the macro.
The SVE LUT instructions were using the lut instruction class, which
has special handling only for SIMD operands, and isn't recognised by
aarch64_decode_variant_using_iclass (which sets the qualifiers during
decode for most SVE instructions). To prevent these instructions
failing to disassemble, I changed their instruction class to sve_misc.
Many instructions explicitly specified SVE/SVE2/SME/SME2 as a required
feature when it was already implied by another required feature (at
least while the SME->SVE2 implication is retained internally). These
redundant features were used to determine both the valid symbol names
for immediate operands, and the choice of error message for invalid
movprfx sequences. Those two scenarios no longer use architecture
features, so the redundant features are now truly redundant.
Previously the choice of error message for an invalid movprfx sequence
used the architecture requirements to determine whether an instruction
was an SVE instruction or not. This meant specifying SVE or SVE2 as an
explicit architecture requirement for all SVE instructions, even when
this was already implied by another feature. As more architecture
features are added and with the partial removal of the SME->SVE2
dependency, these extra feature requirements were getting messier and
easier to forget.
Instead, we now look at the operand types. If there is an SVE_REG,
SVE_REGLIST or PRED_REG operand, then we treat the instruction as an SVE
instruction. This does change behaviour slightly, but it only affects
the choice of error message and the new choice should be a bit more
consistent.
There is one testsuite update required, because Ezra's SVE_AES2 patch
temporarily broke classification of FEAT_SVE_AES instructions. This
patch restores the original behaviour.
When parsing immediate values, register names should not be
misinterpreted as symbols. However, for backwards compatibility we need
to permit some newer register names within older instructions. The
current mechanism for doing so depends on the list of explicit
architecture requirements for the instructions, which is fragile and
easy to forget, and grows increasingly messy as more architecture
features are added.
This patch add explicit flags to each opcode to indicate which set of
register names is disallowed in each instance. These flags are
mandatory for all opcodes with immediate operands, which ensures that
the choice of disallowed names will always be deliberate and explicit.
This patch should have no functional change.
FEAT_SVE_AES2 implements the SVE multi-vector Advanced Encryption
Standard and 128-bit destination element polynomial multiply long
instructions, when the PE is not in Streaming SVE mode.
FEAT_PCDPHINT - Producer-consumer data placement hints - is an optional
ISA extension that provides hint instructions to indicate:
- a store in the current execution thread is generating data at a specific
location, which a thread of execution on one or more other observers is
waiting on.
- the thread of execution on the current PE will read a location that may not
yet have been written with the value to be consumed.
This extension introduces:
- STSHH, a hint instruction, with operands (policies) keep and strm
- PRFM *IR*, a new prefetch memory operand.
Swap AM_PO_SUBDIRS and ZW_GNU_GETTEXT_SISTER_DIR lines in
*/configure.ac. ZW_GNU_GETTEXT_SISTER_DIR indirectly invokes
AC_REQUIRE(AM_PO_SUBDIRS) so results in AM_PO_SUBDIRS being emitted
before ZW_GNU_GETTEXT_SISTER_DIR if it hasn't already been invoked.
This also fix the imply result for .option rvc.
Imply zcf when c and f and rv32
Imply zcd when c and d
Imply zca when c
Changed INSN_CLASS_C to INSN_CLASS_ZCA
Changed INSN_CLASS_F_AND_C to INSN_CLASS_ZCF
Changed INSN_CLASS_D_AND_C to INSN_CLASS_ZCD
Changed INSN_CLASS_ZIHINTNTL_AND_C to INSN_CLASS_ZIHINTNTL_AND_ZCA
This patch add support for FEAT_PoPS feature which can be enabled
through +pops command line flag.
This patch also adds support for following DC instructions and the
spec can be found here [1].
1. "dc cigdvaps" enabled on passing +memtag+pops command line flags.
2. "dc civaps" enabled on passing +pops command line flag.
[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Instructions?lang=en
There are some OpenRISC CPUs that have their binaries stored in
little-endian format. Using objdump to disassemble these is
problematic, as some instructions fail to disassemble, for example:
objdump -D -b binary -EB -m or1k test_be.bin
0: 18 60 07 27 l.movhi r3,0x727
4: a8 63 0e 00 l.ori r3,r3,0xe00
8: 9c 63 ff ff l.addi r3,r3,-1
c: bc 43 00 00 l.sfgtui r3,0
10: 13 ff ff fe l.bf 0x8
14: 44 00 48 00 l.jr r9
objdump -D -b binary -EL -m or1k test_le.bin
0: 27 07 60 18 *unknown*
4: 00 0e 63 a8 l.ori r3,r3,0xe00
8: ff ff 63 9c *unknown*
c: 00 00 43 bc l.sfgtui r3,0
10: fe ff ff 13 *unknown*
14: 00 48 00 44 l.jr r9
It was found that the hash function was using the still little-endian
buffer to extract the opcode used for the hash lookup. This didn't work
as it was pulling the wrong hashcode causing instruction lookup to fail.
Fix the hash function by using the normalized/byte-swapped value instead
of the buffer.
Signed-off-by: Stafford Horne <shorne@gmail.com>
This patch adds support for following system registers and the spec
can be found here[1].
1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE
and Armv9.5-A architecture and these are enabled by passing
-march=armv9.5-a+profile.
2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture
and these are enabled by passing -march=armv9.5-a.
3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing
-march=armv8.8-a.
[1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Registers?lang=en
FEAT_SVE_F16F32MM introduces the SVE half-precision floating-point
matrix multiply-accumulate to single-precision instruction.
FEAT_F8F32MM introduces the Advanced SIMD 8-bit floating-point matrix
multiply-accumulate to single-precision instruction.
FEAT_F8F16MM introduces the Advanced SIMD 8-bit floating-point matrix
multiply-accumulate to half-precision instruction.
