Previously GAS would accept .u32, .u16 and .u8 suffixes to the VQ(R)DMLAH and VQ(R)DMLASH
instructions, however the Armv8.1-M Mainline specification states that these functions only
have signed variations (.s32, .s16 and .s8 suffixes).
This is documented here:
https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf?_ga=2.143079093.1892401233.1563295591-999473562.1560847439#page=1183
gas * config/tc-arm.c (do_mve_vqdmlah): Use N_S_32 macro.
(do_neon_qrdmlah): Use N_S_32 macro.
* testsuite/gas/arm/mve-vqdmlah-bad.d: New test.
* testsuite/gas/arm/mve-vqdmlah-bad.l: New test.
* testsuite/gas/arm/mve-vqdmlah-bad.s: New test.
* testsuite/gas/arm/mve-vqdmlah.d: Remove unsigned instruction tests.
* testsuite/gas/arm/mve-vqdmlah.s: Remove unsigned instruction tests.
* testsuite/gas/arm/mve-vqdmlash-bad.d: New test.
* testsuite/gas/arm/mve-vqdmlash-bad.l: New test.
* testsuite/gas/arm/mve-vqdmlash-bad.s: New test.
* testsuite/gas/arm/mve-vqdmlash.d: Remove unsigned instruction tests.
* testsuite/gas/arm/mve-vqdmlash.s: Remove unsigned instruction tests.
opcodes * arm-dis.c: Only accept signed variants of VQ(R)DMLAH and VQ(R)DMLASH
instructions.
New instruction are added, and some of them are overlapping. Update
disassembler to correctly recognize them. Introduce nps400 option.
opcodes/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* arc-dis.c (skip_this_opcode): Check also for 0x07 major opcodes,
and MPY class instructions.
(parse_option): Add nps400 option.
(print_arc_disassembler_options): Add nps400 info.
gas/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* testsuite/gas/arc/nps400-6.d: Update test.
When SHF_GNU_MBIND was added in the SHF_LOOS to SHF_HIOS range, it
should have required ELFOSABI_GNU since these flags are already in use
by other OSes. HPUX SHF_HP_TLS in fact has the same value. That
means no place in binutils should test SHF_GNU_MBIND without first
checking OSABI, and SHF_GNU_MBIND should not be set without also
setting OSABI. At least, that's the ideal, but the patch accepts
SHF_GNU_MBIND on ELFOSABI_NONE object files since gas didn't always
set OSABI. However, to reinforce the fact that SHF_GNU_MBIND isn't
proper without a non-zero OSABI, readelf will display the flag as
LOOS+0 if OSABI isn't set.
The clash with SHF_HP_TLS means that hppa64-linux either has that flag
on .tbss sections or supports GNU_MBIND, not both. (hppa64-linux
users, if there are any, may have noticed that GNU ld since 2017
mysteriously aligned their .tbss sections to a 4k boundary. That was
one consequence of SHF_HP_TLS being blindly interpreted as
SHF_GNU_MBIND.) Since it seems that binutils, gdb, gcc, glibc, and
the linux kernel don't care about SHF_HP_TLS I took that flag out of
.tbss for hppa64-linux.
bfd/
* elf-bfd.h (enum elf_gnu_osabi): Add elf_gnu_osabi_mbind.
* elf.c (_bfd_elf_make_section_from_shdr): Set elf_gnu_osabi_mbind.
(get_program_header_size): Formatting. Only test SH_GNU_MBIND
when elf_gnu_osabi_mbind is set.
(_bfd_elf_map_sections_to_segments): Likewise.
(_bfd_elf_init_private_section_data): Likewise.
(_bfd_elf_final_write_processing): Update comment.
* elf64-hppa.c (elf64_hppa_special_sections): Move .tbss entry.
(elf_backend_special_sections): Define without .tbss for linux.
binutils/
* readelf.c (get_parisc_segment_type): Split off hpux entries..
(get_ia64_segment_type): ..and these..
(get_hpux_segment_type): ..to here.
(get_segment_type): Condition GNU_MBIND on osabi. Use
get_hpux_segment_type.
(get_symbol_binding): Do not print UNIQUE for ELFOSABI_NONE.
(get_symbol_type): Do not print IFUNC for ELFOSABI_NONE.
gas/
* config/obj-elf.c (obj_elf_change_section): Don't emit a fatal
error for non-SHF_ALLOC SHF_GNU_MBIND here.
(obj_elf_parse_section_letters): Return SHF_GNU_MBIND in new
gnu_attr param.
(obj_elf_section): Adjust obj_elf_parse_section_letters call.
Formatting. Set SHF_GNU_MBIND and elf_osabi from gnu_attr.
Emit normal error for non-SHF_ALLOC SHF_GNU_MBIND and wrong osabi.
(obj_elf_type): Set elf_osabi for ifunc.
* testsuite/gas/elf/section12a.d: xfail msp430 and hpux.
* testsuite/gas/elf/section12b.d: Likewise.
* testsuite/gas/elf/section13.d: Likewise.
* testsuite/gas/elf/section13.l: Adjust expected error.
ld/
* emultempl/elf32.em (gld${EMULATION_NAME}_place_orphan): Condition
SHF_GNU_MBIND on osabi. Set output elf_gnu_osabi_mbind.
The instructions that this change apply to are:
VQDMLADH, VQRDMLADH, VQDMLSDH, VQRDMLSDH
The updated documentation is here: https://static.docs.arm.com/ddi0553/bh/DDI0553B_h_armv8m_arm.pdf
Fixed this by removing the check for this warning from GAS as well as opcodes.
Added testcases to test that the warning is not generated for the instructions that have a 32-bit element size
and the same source and destination operand. Also fixed tests that would previously check for this warning.
gas * config/tc-arm.c (do_mve_vqdmladh): Remove check for UNPREDICTABLE.
* testsuite/gas/arm/mve-vqdmladh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmladh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmladh.d: New tests.
* testsuite/gas/arm/mve-vqdmladh.s: New tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.l: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh-bad.s: Remove tests.
* testsuite/gas/arm/mve-vqdmlsdh.d: New tests.
* testsuite/gas/arm/mve-vqdmlsdh.s: New tests.
opcodes * arm-dis.c (is_mve_unpredictable): Stop marking some MVE
instructions as UNPREDICTABLE.
This patch changes the eBPF CPU description to prefer the register
names %r0 and %r6 instead of %a and %ctx when disassembling. This
matches better with the current practice, vs. cBPF.
It also updates the GAS tests in order to reflect this change.
Tested in a x86_64 host.
cpu/ChangeLog:
2019-07-19 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf.cpu (h-gpr): when disassembling, use %r0 and %r6 instead of
%a and %ctx.
opcodes/ChangeLog:
2019-07-19 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-desc.c: Regenerated.
gas/ChangeLog:
2019-07-19 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/alu.d: Use %r6 instead of %ctx.
* testsuite/gas/bpf/lddw-be.d: Likewise.
* testsuite/gas/bpf/lddw.d: Likewise.
* testsuite/gas/bpf/alu-be.d: Likewise.
* testsuite/gas/bpf/alu32.d: Likewise.
Tested in a x86_64 host.
gas/ChangeLog:
2019-07-19 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.c (pe_lcomm_internal): Adapted from tc-i386.c.
(pe_lcomm): Likewise.
(md_pseudo_table): Use pe_lcomm to implement .lcomm.
After some discussion, we've decided to rename the +bitperm feature
flag to +sve2-bitperm, so that it's consistent with the other SVE2
feature flags. The associated internal macros already used
"SVE2_BITPERM", so only the feature flag itself needs to change.
2019-07-19 Richard Sandiford <richard.sandiford@arm.com>
gas/
* doc/c-aarch64.texi: Remame the +bitperm extension to +sve2-bitperm.
* config/tc-aarch64.c (aarch64_features): Likewise.
* testsuite/gas/aarch64/illegal-sve2-aes.d: Update accordingly.
* testsuite/gas/aarch64/illegal-sve2-sha3.d: Likewise.
* testsuite/gas/aarch64/illegal-sve2-sm4.d: Likewise.
* testsuite/gas/aarch64/illegal-sve2.d: Likewise.
* testsuite/gas/aarch64/sve2.d: Likewise.
This patch supports using pcrel instructions in TLS code sequences. A
number of new relocations are needed, gas operand modifiers to
generate those relocations, and new TLS optimisation. For
optimisation it turns out that the new pcrel GD and LD sequences can
be distinguished from the non-pcrel GD and LD sequences by there being
different relocations on the new sequence. The final "add ra,rb,13"
on IE sequences similarly needs a new relocation, or as I chose, a
modification of R_PPC64_TLS. On pcrel IE code, the R_PPC64_TLS points
one byte into the "add" instruction rather than being on the
instruction boundary.
GD:
pla 3,z@got@tlsgd@pcrel # R_PPC64_GOT_TLSGD34
bl __tls_get_addr@notoc(z@tlsgd) # R_PPC64_TLSGD and R_PPC64_REL24_NOTOC
edited to IE
pld 3,z@got@tprel@pcrel
add 3,3,13
edited to LE
paddi 3,13,z@tprel
nop
LD:
pla 3,z@got@tlsld@pcrel # R_PPC64_GOT_TLSLD34
bl __tls_get_addr@notoc(z@tlsld) # R_PPC64_TLSLD and R_PPC64_REL24_NOTOC
..
paddi 9,3,z2@dtprel
pld 10,z3@got@dtprel@pcrel
add 10,10,3
edited to LE
paddi 3,13,0x1000
nop
IE:
pld 9,z@got@tprel@pcrel # R_PPC64_GOT_TPREL34
add 3,9,z@tls@pcrel # R_PPC64_TLS at insn+1
ldx 4,9,z@tls@pcrel
lwax 5,9,z@tls@pcrel
stdx 5,9,z@tls@pcrel
edited to LE
paddi 9,13,z@tprel
nop
ld 4,0(9)
lwa 5,0(9)
std 5,0(9)
LE:
paddi 10,13,z@tprel
include/
* elf/ppc64.h (R_PPC64_TPREL34, R_PPC64_DTPREL34),
(R_PPC64_GOT_TLSGD34, R_PPC64_GOT_TLSLD34),
(R_PPC64_GOT_TPREL34, R_PPC64_GOT_DTPREL34): Define.
(IS_PPC64_TLS_RELOC): Include new tls relocs.
bfd/
* reloc.c (BFD_RELOC_PPC64_TPREL34, BFD_RELOC_PPC64_DTPREL34),
(BFD_RELOC_PPC64_GOT_TLSGD34, BFD_RELOC_PPC64_GOT_TLSLD34),
(BFD_RELOC_PPC64_GOT_TPREL34, BFD_RELOC_PPC64_GOT_DTPREL34),
(BFD_RELOC_PPC64_TLS_PCREL): New pcrel tls relocs.
* elf64-ppc.c (ppc64_elf_howto_raw): Add howtos for pcrel tls relocs.
(ppc64_elf_reloc_type_lookup): Translate pcrel tls relocs.
(must_be_dyn_reloc, dec_dynrel_count): Add R_PPC64_TPREL64.
(ppc64_elf_check_relocs): Support pcrel tls relocs.
(ppc64_elf_tls_optimize, ppc64_elf_relocate_section): Likewise.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
gas/
* config/tc-ppc.c (ppc_elf_suffix): Map "tls@pcrel", "got@tlsgd@pcrel",
"got@tlsld@pcrel", "got@tprel@pcrel", and "got@dtprel@pcrel".
(fixup_size, md_assemble): Handle pcrel tls relocs.
(ppc_force_relocation, ppc_fix_adjustable): Likewise.
(md_apply_fix, tc_gen_reloc): Likewise.
ld/
* testsuite/ld-powerpc/tlsgd.d,
* testsuite/ld-powerpc/tlsgd.s,
* testsuite/ld-powerpc/tlsie.d,
* testsuite/ld-powerpc/tlsie.s,
* testsuite/ld-powerpc/tlsld.d,
* testsuite/ld-powerpc/tlsld.s: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.
This little patch adds support to the eBPF port of GAS for a few data
directives. The names for the directives have been chosen to be
coherent with the suffixes used in eBPF instructions: b, h, w and dw
for 8, 16, 32 and 64-bit values respectively.
Documentation and tests included.
Tested in a x86_64 host.
gas/ChangeLog:
2019-07-17 Jose E. Marchesi <jose.marchesi@oracle.com>
* config/tc-bpf.c (md_pseudo_table): .half, .word and .dword.
* testsuite/gas/bpf/data.s: New file.
* testsuite/gas/bpf/data.d: Likewise.
* testsuite/gas/bpf/data-be.d: Likewise.
* testsuite/gas/bpf/bpf.exp: Run data and data-be.
* doc/c-bpf.texi (BPF Directives): New section.
Once operand parsing has completed, the simpler check of Operand_Mem can
be used in places where i.types[] got passed to operand_type_check().
Note that this has shown a couple of omissions of adjusting i.flags[]
when playing with i.op[] / i.types[] / i.tm.operand_types[]. Not all of
them get added here, just all of the ones needed in process_operands().
... instead of an operand type bit: It's an insn property, not an
operand one. There's just one actual change to be made to the
templates: Most are now required to have the (unswapped) destination go
into ModR/M.rm, so VMOVD template needs its opcode adjusted accordingly
and its operands swapped. {,V}MOVS{S,D}, otoh, are left alone in this
regard, as otherwise generated code would differ from what we've been
producing so far (which I don't think is wanted).
Take the opportunity and add a missing IgnoreSize to pextrb (leading to
an error in 16-bit mode), and take the liberty to once again drop stray
IgnoreSize attributes from lines changed and neighboring related ones.
They're the only exception to there generally being no mix of register
kinds possible in an insn operand template, and there being two bits per
operand for their representation is also quite wasteful, considering the
low number of uses. Fold both bits and deal with the little bit of
fallout.
Also take the liberty and drop dead code trying to set REX_B: No segment
register has RegRex set on it.
Additionally I was quite surprised that PUSH/POP with the permitted
segment registers is not covered by the test cases. Add the missing
pieces.
This patch fixes the eBPF CPU description in order to reflect the
right explicit arguments passed to the ldabs{b,h,w,dw} instructions,
updates the corresponding GAS tests, and updates the BPF section of
the GAS manual.
cpu/ChangeLog:
2019-07-15 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf.cpu (dlabs): New pmacro.
(dlind): Likewise.
opcodes/ChangeLog:
2019-07-15 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-desc.c: Regenerate.
* bpf-opc.c: Likewise.
* bpf-opc.h: Likewise.
gas/ChangeLog:
2019-07-15 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/mem.s: ldabs instructions do not take a `src'
register as an argument.
* testsuite/gas/bpf/mem.d: Updated accordingly.
* testsuite/gas/bpf/mem-be.d: Likewise.
* doc/c-bpf.texi (BPF Opcodes): Update to reflect the correct
explicit arguments to ldabs and ldind instructions.
The eBPF non-generic load instructions ldind{b,h,w,dw} and
ldabs{b,h,w,dw} do not take an explicit destination register as an
argument. Instead, they put the loaded value in %r0, implicitly.
This patch fixes the CPU BPF description to not expect a 'dst'
argument in these arguments, regenerates the corresponding files in
opcodes, and updates the impacted GAS tests.
Tested in a x86-64 host.
cpu/ChangeLog:
2019-07-14 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf.cpu (dlsi): ldabs and ldind instructions do not take an
explicit 'dst' argument.
opcodes/ChangeLog:
2019-07-14 Jose E. Marchesi <jose.marchesi@oracle.com>
* bpf-desc.c: Regenerate.
* bpf-opc.c: Likewise.
gas/ChangeLog:
2019-07-14 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/mem.s: Do not use explicit arguments for
ldabs and ldind instructions.
* testsuite/gas/bpf/mem.d: Updated accordingly.
* testsuite/gas/bpf/mem-be.d: Likewise.
git commit f2d4ba38f5 caused many failures for mips-sgi-irix targets,
and added a new test that failed for aarch64, nds32, and rl78.
The mips failures are due to BSF_OBJECT being set in many cases for
symbols by the mips .global/.globl directive. This patch removes that
code and instead sets BSF_OBJECT in a target frob_symbol function,
also moving the mips hacks in elf_frob_symbol to the new function.
Note that common symbols are handled fine in elf.c:swap_out_syms
without needing to set BSF_OBJECT, so that old code can disappear.
* config/obj-elf.c (elf_frob_symbol): Remove mips hacks.
* config/tc-mips.h (tc_frob_symbol): Define.
(mips_frob_symbol): Declare.
* config/tc-mips.c (s_mips_globl): Don't set BSF_OBJECT for irix.
(mips_frob_symbol): Fudge symbols for irix here.
* testsuite/gas/elf/type-2.e: Allow random target symbols.
From Kito Cheng <kito.cheng@sifive.com>
gas/ChangeLog
* doc/c-riscv.texi (Instruction Formats): Add r4 type.
* testsuite/gas/riscv/insn.d: Add testcase for r4 type.
* testsuite/gas/riscv/insn.s: Ditto.
* doc/c-riscv.texi (Instruction Formats): Add b and j type.
* testsuite/gas/riscv/insn.d: Add test case for b and j type.
* testsuite/gas/riscv/insn.s: Ditto.
* testsuite/gas/riscv/insn.s: Correct instruction type for load
and store.
* testsuite/gas/riscv/insn.d: Using regular expression to match
address.
* doc/c-riscv.texi (Instruction Formats): Fix encoding table for SB
type and fix typo.
opcode/ChangeLog
* riscv-opc.c (riscv_insn_types): Add r4 type.
* riscv-opc.c (riscv_insn_types): Add b and j type.
* opcodes/riscv-opc.c (riscv_insn_types): Remove incorrect
format for sb type and correct s type.
For another patch I wanted to use a sufficiently benign option (simply
to be able to specify one, which certain test case invocations require),
and I stumbled across -Q in the --help output. Before realizing that
this is x86-specific anyway, I've tried and and ran into a mysterious
testsuite failure, until I further realized that other than the help
text suggests the option requires an argument. Correct the help text,
and make the implementation actually match what the comment there has
been describing (and what the help text now says).
Recently a patch was submitted for a Xen Project test harness binary to
override the compiler specified @object to @func (see [1]). In a reply I
suggested we shouldn't make ourselves dependent on currently unspecified
behavior of gas here: It accumulates all requests, and then
bfd/elf.c:swap_out_syms(), in an apparently ad hoc manner, prioritizes
certain flags over others.
Make the behavior predictable: Generally the last .type is what counts.
Exceptions are directives which set multiple bits (TLS, IFUNC, and
UNIQUE): Subsequent directives requesting just the more generic bit
(i.e. FUNC following IFUNC) won't clear the more specific one. Warn
about incompatible changes, except from/to STT_NOTYPE.
Also add a new target hook, which hppa wants to use right away afaict.
In the course of adding the warning I ran into two ld testsuite
failures. I can only assume that it was a copy-and-paste mistake that
lead to the same symbol having its type set twice.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-05/msg01980.html
For example, when provided with the (incorrect) instruction
st4 {v0.16b-v3.16b}[4],[x0]
currently assembler provides the following error message
"Error: comma expected between operands at operand 2 -- `st4 {v0.16b-v3.16b}[4],[x0]'".
This was due to the assembler consuming the {v0.16b-v3.16b} as the first operand leaving
[4],[x0] as what it believed to be the second operand.
The actual error is that the first operand should be of element type and not
vector type (as provided). The new diagnostic for this error is
"Error: expected element type rather than vector type at operand 1 -- `st4 {v0.16b-v3.16b}[4],[x0]'.
Added testcases to check for the correct diagnostic message as well as checking that
variations of the structural load/store by element instruction also generate the error
when they have the same problem.
* config/tc-aarch64.c (parse_operands): Add error check.
* testsuite/gas/aarch64/diagnostic.l: New test.
* testsuite/gas/aarch64/diagnostic.s: New test.
* testsuite/gas/aarch64/illegal.l: New tests.
* testsuite/gas/aarch64/illegal.s: New tests.
The entry for the FMOV alias of FCPY was missing C_SCAN_MOVPRFX.
(The entry for FCPY itself was OK.)
This was the only /m-predicated instruction I could see that was
missing the flag.
2019-07-02 Richard Sandiford <richard.sandiford@arm.com>
opcodes/
* aarch64-tbl.h (aarch64_opcode): Set C_SCAN_MOVPRFX for the
SVE FMOV alias of FCPY.
gas/
* testsuite/gas/aarch64/sve-movprfx_27.s,
* testsuite/gas/aarch64/sve-movprfx_27.d: New test.
SVE FCVTZS, FCVTZU, SCVTF and UCVTF need the same treatment as FCVT:
the register size used in a predicated MOVPRFX must be the wider of
the destination and source sizes.
Since I was adding a (supposedly) complete set of tests for converts,
it seemed more consistent to add a complete set of tests for shifts
as well, even though there's no bug to fix there.
2019-07-02 Richard Sandiford <richard.sandiford@arm.com>
opcodes/
* aarch64-tbl.h (aarch64_opcode_table): Add C_MAX_ELEM flags
to SVE fcvtzs, fcvtzu, scvtf and ucvtf entries.
gas/
* testsuite/gas/aarch64/sve-movprfx_26.s: Also test FCVTZS, FCVTZU,
SCVTF, UCVTF, LSR and ASR.
* testsuite/gas/aarch64/sve-movprfx_26.d: Update accordingly.
* testsuite/gas/aarch64/sve-movprfx_26.l: Likewise.
One of the MOVPRFX tests has:
output register of preceding `movprfx' used as input at operand 3 -- `cpy z1.d,p1/m,x1'
But X1 and Z1 are not the same register, so the instruction is
actually OK.
2019-07-02 Richard Sandiford <richard.sandiford@arm.com>
opcodes/
* aarch64-opc.c (verify_constraints): Skip GPRs when scanning the
registers in an instruction prefixed by MOVPRFX.
gas/
* testsuite/gas/aarch64/sve-movprfx_25.s: Allow CPY Z1.D.P1/M,X1
to be prefixed by MOVPRFX.
* testsuite/gas/aarch64/sve-movprfx_25.d: Update accordingly.
* testsuite/gas/aarch64/sve-movprfx_25.l: Likewise.
PR 24748
* write.c (create_note_reloc): Add desc2_offset parameter. Change
name of offset parameter to note_offset. Only use desc2_offset
when placing addend into REL reloc's address space.
(maybe_generate_build_notes): Update parameters passed to
create_note_reloc.
I had mistakenly given all variants of the new SVE2 instructions
pmull{t,b} a dependency on the feature +sve2-aes.
Only the variant specifying .Q -> .D sizes should have that
restriction.
This patch fixes that mistake and updates the testsuite to have extra
tests (matching the given set of tests per line in aarch64-tbl.h that
the rest of the SVE2 tests follow).
We also add a line in the documentation of the command line to clarify
how to enable `pmull{t,b}` of this larger size. This is needed because
all other instructions gated under the `sve2-aes` architecture extension
are marked in the instruction documentation by an `HaveSVE2AES` check
while pmull{t,b} is gated under the `HaveSVE2PMULL128` check.
Regtested targeting aarch64-linux.
gas/ChangeLog:
2019-07-01 Matthew Malcomson <matthew.malcomson@arm.com>
* testsuite/gas/aarch64/illegal-sve2-aes.d: Update tests.
* testsuite/gas/aarch64/illegal-sve2.l: Update tests.
* doc/c-aarch64.texi: Add special note of pmull{t,b}
instructions under the sve2-aes architecture extension.
* testsuite/gas/aarch64/illegal-sve2.s: Add small size
pmull{t,b} instructions.
* testsuite/gas/aarch64/sve2.d: Add small size pmull{t,b}
disassembly.
* testsuite/gas/aarch64/sve2.s: Add small size pmull{t,b}
instructions.
include/ChangeLog:
2019-07-01 Matthew Malcomson <matthew.malcomson@arm.com>
* opcode/aarch64.h (enum aarch64_insn_class): sve_size_013
renamed to sve_size_13.
opcodes/ChangeLog:
2019-07-01 Matthew Malcomson <matthew.malcomson@arm.com>
* aarch64-asm.c (aarch64_encode_variant_using_iclass): Use new
sve_size_13 icode to account for variant behaviour of
pmull{t,b}.
* aarch64-dis-2.c: Regenerate.
* aarch64-dis.c (aarch64_decode_variant_using_iclass): Use new
sve_size_13 icode to account for variant behaviour of
pmull{t,b}.
* aarch64-tbl.h (OP_SVE_VVV_HD_BS): Add new qualifier.
(OP_SVE_VVV_Q_D): Add new qualifier.
(OP_SVE_VVV_QHD_DBS): Remove now unused qualifier.
(struct aarch64_opcode): Split pmull{t,b} into those requiring
AES and those not.
It is pretty wasteful to have a per-operand flag which is used in
exactly 4 cases. It can be relatively easily replaced, and by doing so
I've actually found some dead code to remove at the same time (there's
no case of ImmExt set at the same time as Vec_Imm4).
In quite a few cases ImmExt gets used when there's not really any
immediate, but rather a degenerate ModR/M byte. ENCL{S,U} show how this
case is supposed to be dealt with. Eliminate most abuses, leaving in
place (for now) only ones where process_immext() is involved.
It seems to be not uncommon for people to use AND or OR in this form for
just setting the status flags. TEST, which doesn't write to any
register other than EFLAGS, ought to be preferred. Make the change only
for -O2 and above though, at least for now.
When they're in the 0F opcode space, swapping their source operands may
allow switching from 3-byte to 2-byte VEX prefix encoding. Note that NaN
behavior precludes us doing so for many packed and scalar floating point
insns; such an optimization would need to be done by the compiler
instead in this case, when it knows that NaN-s have undefined behavior
anyway.
While for explicitly specified AVX/AVX2 insns the optimization (for now
at least) gets done only for -O2 and -Os, it is utilized by default in
SSE2AVX mode, as there we're re-writing the programmer's specified insns
anyway.
Rather than introducing a new attribute flag, the change re-uses one
which so far was meaningful only for EVEX-encoded insns.
This implication allows to simplify some conditionals, thus slightly
improving performance. This change also paves the way for re-using
StaticRounding for non-EVEX insns.
As long as there's no write mask as well as no broadcast, and as long
as the scaled Disp8 wouldn't result in a shorter EVEX encoding, encode
VPAND{D,Q}, VPANDN{D,Q}, VPOR{D,Q}, and VPXOR{D,Q} acting on only the
lower 16 XMM/YMM registers using their VEX equivalents with -O1.
Also take the opportunity and avoid looping twice over all operands
when dealing with memory-with-displacement ones.
While the ISA extensions doc suggests them to be made available just
like the SDM does for the PCLMULQDQ ISA extension, these weren't added
when supposrt for the new extension was introduced.
Also make sure the 64-bit non-AVX512 test actually tests VEX encodings,
not EVEX ones.
For example, this code is invalid:
smc #0x6951
The code would previously check for and encode for up to 16 bit immediate values, however
this immediate should instead be only a 4 bit value
(as documented herehttps://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf ).
Fixed this by adding range checks in the relevant areas and also removing code that would
encode more than the first 4 bits of the immediate (code that is now redundant, as any immediate operand
larger than 0xF would error now anyway).
gas * config/tc-arm.c (do_smc): Add range check for immediate operand.
(do_t_smc): Add range check for immediate operand. Remove
obsolete immediate encoding.
(md_apply_fix): Fix range check. Remove obsolete immediate encoding.
* testsuite/gas/arm/arch6zk.d: Fix test.
* testsuite/gas/arm/arch6zk.s: Fix test.
* testsuite/gas/arm/smc-bad.d: New test.
* testsuite/gas/arm/smc-bad.l: New test.
* testsuite/gas/arm/smc-bad.s: New test.
* testsuite/gas/arm/thumb32.d: Fix test.
* testsuite/gas/arm/thumb32.s: Fix test.
These encodings aren't valid in real and VM86 modes, but they are very
well usable in 16-bit protected mode.
A few adjustments in the disassembler tables are needed where Ev or Gv
were wrongly used. Additionally an adjustment is needed to avoid
printing "addr32" when that's already recognizable by the use of %eiz.
Furthermore the Iq operand template was wrong for XOP:0Ah encoding
insns: They're having a uniform 32-bit immediate. Drop Iq and introduce
Id instead.
Clone a few existing test cases to exercise assembler and disassembler.
Noticed by a customer while looking at a tangentially related problem. The
gas testsuite for xstormy16 has two scripts that have a typo on the first
line, they are missing the !. They also use shell syntax that doesn't work
on a system where /bin/sh is dash. So I fixed the typo, changed the shell
to bash, and made them executable, so that they now work when run directly
even if /bin/sh is dash.
gas/
* testsuite/gas/xstormy16/allinsn.sh: Change first line to
#!/bin/bash and make it executable.
* testsuite/gas/xstormy16/gcc.sh: Likewise.
