This patch adds support for Check Feature Status Extension (CHK) which
is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
(hint #40).
Given the shared use of the aarch64-sys-regs.def file across Binutils
and GCC, add instructions for keeping the file synchronized across the
two codebases.
Namely, it should be made clear that all changes are first to be made
in Binutils and the updated file copied across to GCC.
opcodes/ChangeLog
* opcodes/aarch64-sys-regs.def: Update file-description header
comment.
There is currently a bug in the bit masking for the barrel shift
instructions because the bit mask is not including all of the
register bits which must be zero. With this patch, the disassembler
can be sure that the 32-bit value is indeed a barrel shift instruction
and not a data value in memory.
This fix can be verified by assembling and disassembling the following:
.text
.long 0x65005f5f
With this patch, the bug is fixed, and the objdump will know that
0x65005f5f is not a barrel shift instruction.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
This patches adds new bsefi and bsifi instructions.
BSEFI- The instruction shall extract a bit field from a
register and place it right-adjusted in the destination register.
The other bits in the destination register shall be set to zero.
BSIFI- The instruction shall insert a right-adjusted bit field
from a register at another position in the destination register.
The rest of the bits in the destination register shall be unchanged.
Further documentation of these instructions can be found here:
https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref
With version 6 of the patch, no new relocation types are added as
this was unnecessary for adding the bsefi and bsifi instructions.
FIXED: Segfault caused by incorrect termination of microblaze_opcodes.
Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>
opcodes/
* riscv-dis.c (riscv_get_map_state): allow mapping symbol to
be suffixed by a unique identifier .<any>
This patches adds new bsefi and bsifi instructions.
BSEFI- The instruction shall extract a bit field from a
register and place it right-adjusted in the destination register.
The other bits in the destination register shall be set to zero.
BSIFI- The instruction shall insert a right-adjusted bit field
from a register at another position in the destination register.
The rest of the bits in the destination register shall be unchanged.
Further documentation of these instructions can be found here:
https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref
This patch has been tested for years of AMD Xilinx Yocto
releases as part of the following patch set:
https://github.com/Xilinx/meta-xilinx/tree/master/meta-microblaze/recipes-devtools/binutils/binutils
Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
This patch moves instances of system register definitions, represented
by the SYSREG macro, out of their original place in `aarch64-opc.c'
and into a dedicated .def file, `aarch64-sys-regs.def'.
System register entries in this new file are ordered alphabetically by
name. This choice is made to enable the use of fast search algorithms
such as binary search when validating register names.
The SYSREG macro, defined as SYSREG (name, encoding, flags, features)
is kept as is and used in the def file, but all other SR_* macros
which previously served as indirections to SYSREG are removed.
opcodes/ChangeLog:
* aarch64-opc.c (SR_CORE): Macro definition and uses deleted.
(SR_FEAT): Likewise.
(SR_FEAT2): Likewise.
(SR_V8_1_A): Likewise.
(SR_V8_4_A): Likewise.
(SR_V8A): Likewise.
(SR_V8R): Likewise.
(SR_V8_1A): Likewise.
(SR_V8_2A): Likewise.
(SR_V8_3A): Likewise.
(SR_V8_4A): Likewise.
(SR_V8_6A): Likewise.
(SR_V8_7A): Likewise.
(SR_V8_8A): Likewise.
(SR_GIC): Likewise.
(SR_AMU): Likewise.
(SR_LOR): Likewise.
(SR_PAN): Likewise.
(SR_RAS): Likewise.
(SR_RNG): Likewise.
(SR_SME): Likewise.
(SR_SSBS): Likewise.
(SR_SVE): Likewise.
(SR_ID_PFR2): Likewise.
(SR_PROFILE): Likewise.
(SR_MEMTAG): Likewise.
(SR_SCXTNUM): Likewise.
(SR_EXPAND_ELx): Likewise.
(SR_EXPAND_EL12): Likewise.
* opcodes/aarch64-sys-regs.def: New.
This patch adds a mechanism for system register name alias detection
to register-matching mechanisms.
A new `F_REG_ALIAS' flag is added to the set of register flags and
used to label which entries in aarch64_sys_regs[] correspond to
aliases (and thus which CPENC values are non-unique in this array).
Where this is used is, for example, in `aarch64_print_operand' where,
in the case of system register decoding, the aarch64_sys_regs[] array
is iterated through until a match in CPENC value is made and the first
match accepted. If insufficient care is given in the ordering of
system registers in this array, the alias is encountered before the
"real" register and used incorrectly as the register name in the
disassembled output.
With this flag and the new `aarch64_sys_reg_alias_p' test, search
candidates corresponding to aliases can be conveniently skipped over.
One concrete example of where this is useful is with the
`trcextinselr0' system register. It was initially placed in the
system register list before `trcextinselr', in contrast to a more
natural alphabetical order.
include/ChangeLog:
* opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_reg_alias_p): New.
(aarch64_print_operand): add aarch64_sys_reg_alias_p check.
(aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr"
entry.
* aarch64-opc.h (F_REG_ALIAS): New.
Following the folding of some generic AVX/AVX2 templates with their
AVX512F counterpart ones, do this for FMA ones as well, requiring one
further adjustment to cpu_flags_match().
In anticipation of APX introduce logic to reduce the number of templates
we have now, allowing to limit some the number of ones we then need to
gain.
The fundamental requirements are that
- attributes be compatible, which specifically means VexW needs to be
the same in the templates (which often isn't the case, for VEX
encodings having far more WIG tha, EVEX ones),
- the EVEX form being AVX512F (with or without AVX512VL), not any of its
extensions (the same will then be required for APX - it'll need to be
APX_F).
Note that in check_register() there's now a redundant zmm check. Since
this logic will need revisiting for APX anyway, I'd like to keep it that
way for now. (Similarly a couple of if()-s which could be folded are
kept separate, to reduce code churn when adding APX support.)
Add a macro pcaddi instruction to support "pcaddi rd, symbol".
pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative
address, and the address should be 4-byte aligned.
The AArch64 feature-flag code is currently limited to a maximum
of 64 features. This patch reworks it so that the limit can be
increased more easily. The basic idea is:
(1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum
counting bit positions.
(2) Make the feature-list macros take an array index argument
(currently always 0). The macros then return the
aarch64_feature_set contents for that array index.
An N-element array would then be initialised as:
{ MACRO (0), ..., MACRO (N - 1) }
(3) Provide convenience macros for initialising an
aarch64_feature_set for:
- a single feature
- a list of individual features
- an architecture version
- an architecture version + a list of additional features
(2) and (3) use the preprocessor to generate static initialisers.
The main restriction was that uses of the same preprocessor macro
cannot be nested. So if a macro wants to do something for N individual
arguments, it needs to use a chain of N macros to do it. There then
needs to be a way of deriving N, as a preprocessor token suitable for
pasting.
The easiest way of doing that was to precede each list of features
by the number of features in the list. So an aarch64_feature_set
initialiser for three features A, B and C would be written:
AARCH64_FEATURES (3, A, B, C)
This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a
synonym for SHA2+AES, so the patch expands the former to the latter.
Now that CpuLM is used solely in cpu_arch_flags and cpu_arch[] while
Cpu64 is solely used in insn templates, they no longer need to be
treated different from other "ordinary" flags; the only "unusual" one
left if CpuNo64. Fold both, leaving just Cpu64.
Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
operand purpose isn't properly reflected in Vxy's definition. Rename
"dst" to "src", thus bringing things in line with Exy.
Recognize "/<number>" suffixes on both -march=+avx10.1 and the
corresponding .arch directive, setting an upper bound on the vector size
that insns may use. Such a restriction can be reset by setting a new base
architecture, by using a suffix-less form, by disabling AVX10, or by
enabling any other VEX/EVEX-based vector extension.
While for most insns we can suppress their use with too wide operands
via registers becoming unavailable (or in Intel syntax memory operand
size specifiers not being recognized), mask register insns have to have
their minimum required vector size specified in a new attribute. (Of
course this new attribute could also be used on other insns.)
Note that .insn continues to be permitted to emit EVEX{512,256} (and
VEX256 ones) encodings regardless of vector size restrictions in place.
Of course these can't be expressed using zmm (or ymm) operands then,
but need using the EVEX.512.* forms (broadcast forms may be usable right
now, but this may go away so shouldn't be relied upon). This is why no
assertions should be added to build_{e,}vex_prefix().
Since this is merely a re-branding of certain AVX512* features, there's
little code to be added.
The main aspect here are new testcases. In order to be able to re-use
some of the existing testcases, several of them need their start symbols
adjusted. Note that 256- and 128-bit tests want adding here, as these
need to work right away. Subsequently they'll gain vector length
constraints.
Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
test.
These probably should have been put in place already anyway, but they're
very much wanted in order to then put AVX10.1 support on top. Note that
to avoid reverse dependencies towards SSE (just like we already do for
AVX and XOP), add_isa_dependencies() needs some further tweaking.
While there also address a related anomaly: Disabling AES but neither
AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
VEX-encoded forms available. Note that for this the VAES insns are moved
past the AVX+AES ones, to avoid the property-11 test suddenly failing.
The test really is wrong, but let's not also make things inconsistent:
Without the movement, YMM use would be correctly recorded for the
128-bit forms simply because the first template already matches, as long
as VAES wasn't disabled. Yet it still wouldn't be if only AVX+AES were
enabled. Nor would behavior here then be the same as for VPCLMUL* insns.
gprofng uses insn_type in print_address_func().
But insn_type is always zero on aarch64.
opcodes/ChangeLog:
2023-09-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
branch instructions.
While the patch already committed for pr30793 prevents the asan error,
there is a problem: Now the last element of bundle_words never gets
written. That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
So this patch rearranges things a little to support writing of all of
bundle_words and does the parallel bit checking only when filling
bundle_words. In the normal case, kvx_reassemble_bundle will see
bundle_words[word_count-1] with the parallel bit clear and all other
words having it set. In the error case where all words in
bundle_words have the parallel bit set, kvx_reassemble_bundle will be
passed a wordcount of KVXMAXBUNDLEWORDS + 1. I've also made
kvx_reassemble_bundle return true for success rather than zero, and
removed the unnecessary check for zero wordcount.
PR 30793
* kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
Fail if wordcount is too large. Don't check for wordcount zero.
Don't check kvx_has_parallel_bit.
(print_insn_kvx): Rewrite code reading bundle_words as a for loop.
Don't stop reading at KVXMAXBUNDLEWORDS - 1.
(decode_prologue_epilogue_bundle): Similarly.
The vendor operands should be named starting with `X', and preferably the
second letter (or multiple following letters) is enough to differentiate
them from other vendors.
Therefore, added letter `t' after `X' for t-head operands, to differentiate
from future different vendor's operands.
bfd/
* elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
document link since it should already be recorded in the
gas/doc/c-riscv.texi.
gas/
* config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
t-head operands. Minor updates for indents and comments.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Minor updates.
opcodes/
* riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
operands. Minor updates for indents and comments.
* riscv-opc.c (riscv_opcode): Likewise.
There's no need to have almost identical code twice. Do away with
M_VMSGEU and instead simply use an unused (for these macros) field to
tell apart both variants.
The name we use internally isn't in line with the SDM, and also isn't in
line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave
alone user facing names.
Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was
right in adding the attribute to MOVQ, but there was no need to add it
to VMOVQ. (See also the AVX512F form, which doesn't have the attribute
either.)
For disassembly to only use spec-mandated aliases, respective non-alias
entries need to come ahead of their alias ones. Since identical
mnemonics need to stay together, whole groups are moved up where
necessary.
This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for
consistent alias handling"), but then also goes beyond a plain revert.
Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual
only defines them only for RV64 (because all Ventana's processors implement
RV64).
This commit limits XVentanaCondOps instructions RV64-only to match the
behavior of the manual and LLVM.
Note that this commit alone will not make XVentanaCondOps extension with
RV32 invalid (it just makes XVentanaCondOps on RV32 empty).
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn"
to XLEN=64.
gas/ChangeLog:
* testsuite/gas/riscv/x-ventana-condops-32.d: New failure test.
* testsuite/gas/riscv/x-ventana-condops-32.l: Likewise.
This patch sets GUILE to just plain 'guile'.
In the distant ("devo") past, the top-level build did support building
Guile in-tree. However, I don't think this really works any more.
For one thing, there are no build dependencies on it, so there's no
guarantee it would actually be built before the uses.
This patch also removes the use of "-s" as an option to cgen scheme
scripts. With my latest patch upstream, this is no longer needed.
After the upstream changes, either Guile 2 or Guile 3 will work, with
or without the compiler enabled.
2023-08-24 Tom Tromey <tom@tromey.com>
* cgen.sh: Don't pass "-s" to cgen.
* Makefile.in: Rebuild.
* Makefile.am (GUILE): Simplify.
i386: warning: format ‘%u’ expects argument of type ‘unsigned int’,
but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
ia64: warning: ignoring return value of ‘fgets’
* i386-gen.c (process_i386_opcodes): Correct format string.
* ia64-gen.c (load_insn_classes, load_depfile): Don't ignore
fgets return value.
opcodes/
* kvx-dis.c (print_insn_kvx): Change the loop condition so that
wordcount is always less than KVXMAXBUNDLEWORDS.
(decode_prologue_epilogue_bundle): Likewise.
Historically, flags and variables relating to architectural revisions
for the A-profile architecture omitted the trailing `A' such that, for
example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
flag in the assembler.
This leads to some ambiguity, since Binutils also targets the
R-profile Arm architecture. Therefore, it seems prudent to have
everything associated with the A-profile cores end in `A' and likewise
`R' for the R-profile. Referring back to the example above, the flag
set for `-march=armv8.4-a' is better characterized if labeled
`AARCH64_ARCH_V8_4A'.
The only exception to the rule of appending `A' to variables is found
in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
baseline from which ALL processors derive and should therefore be left
unchanged.
In reflecting the `ARM' architectural nomenclature choices, where we
have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
an underscore separating the numerical revision number and the
A/R-profile indicator suffix. This has meant that renaming of
R-profile related flags and variables was warranted, thus going from
`.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.
Finally, this is more in line with conventions within GCC and adds consistency
across the toolchain.
gas/ChangeLog:
* gas/config/tc-aarch64.c:
(aarch64_cpus): Reference to arch feature macros updated.
(aarch64_archs): Likewise.
include/ChangeLog:
* include/opcode/aarch64.h:
(AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A.
(AARCH64_FEATURE_V8_1A): A-suffix added.
(AARCH64_FEATURE_V8_2A): Likewise.
(AARCH64_FEATURE_V8_3A): Likewise.
(AARCH64_FEATURE_V8_4A): Likewise.
(AARCH64_FEATURE_V8_5A): Likewise.
(AARCH64_FEATURE_V8_6A): Likewise.
(AARCH64_FEATURE_V8_7A): Likewise.
(AARCH64_FEATURE_V8_8A):Likewise.
(AARCH64_FEATURE_V9A): Likewise.
(AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R.
(AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A_FEATURES): A-suffix added.
(AARCH64_ARCH_V8_2A_FEATURES): Likewise.
(AARCH64_ARCH_V8_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8_4A_FEATURES): Likewise.
(AARCH64_ARCH_V8_5A_FEATURES): Likewise.
(AARCH64_ARCH_V8_6A_FEATURES): Likewise.
(AARCH64_ARCH_V8_7A_FEATURES): Likewise.
(AARCH64_ARCH_V8_8A_FEATURES): Likewise.
(AARCH64_ARCH_V9A_FEATURES): Likewise.
(AARCH64_ARCH_V9_1A_FEATURES): Likewise.
(AARCH64_ARCH_V9_2A_FEATURES): Likewise.
(AARCH64_ARCH_V9_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8A): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A): A-suffix added.
(AARCH64_ARCH_V8_2A): Likewise.
(AARCH64_ARCH_V8_3A): Likewise.
(AARCH64_ARCH_V8_4A): Likewise.
(AARCH64_ARCH_V8_5A): Likewise.
(AARCH64_ARCH_V8_6A): Likewise.
(AARCH64_ARCH_V8_7A): Likewise.
(AARCH64_ARCH_V8_8A): Likewise.
(AARCH64_ARCH_V9A): Likewise.
(AARCH64_ARCH_V9_1A): Likewise.
(AARCH64_ARCH_V9_2A): Likewise.
(AARCH64_ARCH_V9_3A): Likewise.
(AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R.
opcodes/ChangeLog:
* opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A.
(SR_V8_1A): A-suffix added.
(SR_V8_2A): Likewise.
(SR_V8_3A): Likewise.
(SR_V8_4A): Likewise.
(SR_V8_6A): Likewise.
(SR_V8_7A): Likewise.
(SR_V8_8A): Likewise.
(aarch64_sys_regs): Reference to arch feature macros updated.
(aarch64_pstatefields): Reference to arch feature macros updated.
(aarch64_sys_ins_reg_supported_p): Reference to arch feature macros
updated.
* opcodes/aarch64-tbl.h:
(aarch64_feature_v8_2a): a-suffix added.
(aarch64_feature_v8_3a): Likewise.
(aarch64_feature_fp_v8_3a): Likewise.
(aarch64_feature_v8_4a): Likewise.
(aarch64_feature_fp_16_v8_2a): Likewise.
(aarch64_feature_v8_5a): Likewise.
(aarch64_feature_v8_6a): Likewise.
(aarch64_feature_v8_7a): Likewise.
(aarch64_feature_v8r): Updated name: v8_r-> v8r.
(ARMV8R): Updated name: V8_R-> V8R.
(ARMV8_2A): A-suffix added.
(ARMV8_3A): Likewise.
(FP_V8_3A): Likewise.
(ARMV8_4A): Likewise.
(FP_F16_V8_2A): Likewise.
(ARMV8_5): Likewise.
(ARMV8_6A): Likewise.
(ARMV8_6A_SVE): Likewise.
(ARMV8_7A): Likewise.
(V8_2A_INSN): `A' added to macro symbol.
(V8_3A_INSN): Likewise.
(V8_4A_INSN): Likewise.
(FP16_V8_2A_INSN): Likewise.
(V8_5A_INSN): Likewise.
(V8_6A_INSN): Likewise.
(V8_7A_INSN): Likewise.
(V8R_INSN): Updated name: V8_R-> V8R.
kvx_dis_init currently always returns true, but error conditions do so
by "return -1" which converts to true. The return status is ignored
anyway, and it doesn't make much sense to error on unexpected arch or
mach: If print_insn_kvx is called then the atch is known to be kvx,
and it's better to choose some default for a user passing an unknown
mach value rather than segfaulting in decode_insn when env.opc_table
is NULL.
I've chosen the default mach to be bfd_mach_kv3_1, the default in
bfd/cpu-kvx.c, not that it matters very much. In normal objdump/gdb
usage, info->mach won't be an unexpected value.
* kvx-dis.c (kvx_dis_init): Return void. Don't error on
unexpected arch or mach. Default to bfd_mach_kv3_1 for
unknown mach. Don't clear info->disassembler_options.
The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
source bit, despite operating on registers. If BPF_SRC_X (=1) is set,
the instructions are rejected by the kernel.
Because of this there are also no neg/neg32 instructions which operate
on immediates, so remove them.
bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old
CGEN-based port, but was not carried forward in the new port.
include/
* opcode/bpf.h (enum bpf_insn_id): Remove spurious entries
BPF_INSN_NEGI and BPF_INSN_NEG32I.
opcodes/
* bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I
instructions.
gas/
* doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and
neg32 instructions operating on immediates.
* testsuite/gas/bpf/alu.s: Adapt accordingly.
* testsuite/gas/bpf/alu.d: Likewise.
* testsuite/gas/bpf/alu-be.d: Likewise
* testsuite/gas/bpf/alu32.s: Likewise.
* testsuite/gas/bpf/alu32.d: Likewise.
* testsuite/gas/bpf/alu32-be.d: Likewise.
* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.
I had reason yesterday to want to regenerate configury files which I
do with --enable-maintainer-mode, and added --enable-cgen-maint
accidentally. The first problem I hit is that sim looks for cgen in a
different directory by default than opcodes, and I had my source
layout set up for opcodes rather than sim. Fix that by making both
use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The
next problem was that various sim local.mk files expected generated
sources in the build dir rather than the source dir. Fix that by
adding $(srcdir) to paths. Finally, the generated iq2000 files had a
compile error, fixed by the cpu/iq2000.cpu patch.
cpu/
* iq2000.cpu (syscall): Add pc arg.
opcodes/
* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
if found there.
* configure: Regenerate.
sim/m4/
* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
sim/
* cris/local.mk: Add $(srcdir) to paths for regenerated source.
* frv/local.mk: Likewise.
* iq2000/local.mk: Likewise.
* lm32/local.mk: Likewise.
* m32r/local.mk: Likewise.
* or1k/local.mk: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
The documentation of the 'Zfa' extension states that "fli.h" is available
"if the Zfh or Zvfh extension is implemented" (both the latest and the
oldest editions are checked).
This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
extensions are implemented.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add new
instruction class handling.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zfa-zvfh.s: New test.
* testsuite/gas/riscv/zfa-zvfh.d: Ditto.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.
This commit adds 'Zihintntl' extension and its hint instructions.
This is based on:
<0dc91f505e>,
the first ISA Manual noting that the 'Zihintntl' extension is ratified.
Note that compressed 'Zihintntl' hints require either 'C' or
'Zca' extension.
Co-authored-by: Nelson Chu <nelson@rivosinc.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
standard hint 'Z' extension.
(riscv_multi_subset_supports): Support new instruction classes.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
including auto-compression without C prefix and explicit C prefix.
* testsuite/gas/riscv/zihintntl.d: Likewise.
* testsuite/gas/riscv/zihintntl-na.d: Likewise.
* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
between 'Zihintntl' and base 'I' or 'C' instructions.
* testsuite/gas/riscv/zihintntl-base.d: Likewise.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
(MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
MATCH_C_NTL_ALL): New.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Add instructions from the
'Zihintntl' extension.
The longest register name is 4 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.
To avoid old gcc, when generating 32-bit code, bogusly warning about
bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
a 64-bit value, and it also doesn't need to - all operand fields to
date are far more narrow than 32 bits. This in turn allows dropping a
number of casts elsewhere.
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.