aboutsummaryrefslogtreecommitdiff
path: root/opcodes
AgeCommit message (Collapse)AuthorFilesLines
2023-06-21x86: fix expansion of %XVJan Beulich1-7/+8
Only %LV should continue on to S handling; avoid emitting a stray 'l' (typically) in suffix-always mode.
2023-06-16x86: shrink Masking insn attribute to a single bit (boolean)Jan Beulich3-1635/+1627
The logic can actually be expressed with less code that way, utilizing that there are common patterns of when which form of masking is permitted. This then also eliminates the large set of open-codings of BOTH_MASKING in the opcode table.
2023-06-15Add additional missing Allegrex CPU instructionsDavid Guillen Fandos1-14/+24
Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with some encoding differences) such as bit manipulation (ins/ext) and MLA (madd/msub). It also features some new instructions like wsbw and min/max or device-specific ones such as mfic. Signed-off-by: David Guillen Fandos <david@davidgf.net>
2023-06-15Add rotation instructions to MIPS Allegrex CPUDavid Guillen Fandos1-7/+7
The Allegrex CPU supports bit rotation instructions as described in the MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU). Signed-off-by: David Guillen Fandos <david@davidgf.net>
2023-06-15Add MIPS Allegrex CPU as a MIPS2-based CPUDavid Guillen Fandos2-26/+32
The Allegrex CPU was created by Sony Interactive Entertainment to power their portable console, the PlayStation Portable. The pspdev organization maintains all sorts of tools to create software for said device including documentation. Signed-off-by: David Guillen Fandos <david@davidgf.net>
2023-06-15Revert "MIPS: add MT ASE support for micromips32"Maciej W. Rozycki2-68/+1
This reverts commit acce83dacff0ce43677410c67aaae32817afe991. It was applied unapproved.
2023-06-15Revert "MIPS: sync oprand char usage between mips and micromips"Maciej W. Rozycki1-18/+10
This reverts commit 5b207b919483f67311a73dfc1de8897ecfd8e776. It was applied unapproved.
2023-06-05MIPS: sync oprand char usage between mips and micromipsYunQiang Su1-10/+18
We should try our best to make mips32 using the same oprand char with micromips. So for mips32, we use: ^ is added for 5bit sa oprand for some new DSPr2 instructions: APPEND, PREPEND, PRECR_SRA[_R].PH.W the LSB bit is 11, like RD. +t is removed for coprocessor 0 destination register. 'E' does the samething. +t is now used for RX oprand for MFTR/MTTR (MT ASE) ? is added for sel oprand for MFTR/MTTR (MT ASE) For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc, while for micromips, they are different. We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2: concatenating rs with rx as the index of control or data.
2023-06-05MIPS: add MT ASE support for micromips32YunQiang Su2-1/+68
These instructions are descripted in MD00768. MIPS® Architecture for Programmers Volume IV-f: The MIPS® MT Module for the microMIPS32™ Architecture Document Number: MD00768 Revision 1.12 July 16, 2013 https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf
2023-06-05Revert "MIPS: add MT ASE support for micromips32"YunQiang Su2-66/+1
This reverts commit 783a5f46b0583e9ed3a63acd3361009f46de5c17.
2023-06-05MIPS: add MT ASE support for micromips32YunQiang Su2-1/+66
These instructions are descripted in MD00768. MIPS® Architecture for Programmers Volume IV-f: The MIPS® MT Module for the microMIPS32™ Architecture Document Number: MD00768 Revision 1.12 July 16, 2013 https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00768-1C-microMIPS32MT-AFP-01.12.pdf
2023-06-01RISC-V: PR30449, Add lga assembler macro support.Jim Wilson1-0/+1
Originally discussion, https://github.com/riscv/riscv-isa-manual/pull/539 Added new load address pseudo instruction which is always expanded to GOT access, no matter the .option rvc is set or not. gas/ PR 30449 * config/tc-riscv.c (macro): Add M_LGA support. * testsuite/gas/riscv/la-variants.d: New. * testsuite/gas/riscv/la-variants.s: New. include/ PR 30449 * opcode/riscv.h (M_LGA): New. opcodes/ PR 30449 * riscv-opc.c (riscv_opcodes): Add lga support.
2023-05-30LoongArch: opcodes: Add support for linker relaxation.mengqinggang1-1/+4
Set gas default to enable relax. opcodes/ChangeLog: * loongarch-opc.c (struct loongarch_ASEs_option): New member relax with the default value 1.
2023-05-26x86: fix disassembler build after 1a3b4f90bc5fJan Beulich1-1/+1
In commit 1a3b4f90bc5f ("x86: convert two pointers to (indexing) integers") I neglected the fact that compilers may warn about comparing ptrdiff_t (signed long) with size_t (unsigned long) values. Since just before we've checked that the value is positive, simply add a cast (despite my dislike for casts).
2023-05-26x86: convert two pointers to (indexing) integersJan Beulich1-16/+17
This in particular reduces the number of pointers to non-const that we have (and that could potentially be used for undue modification of state). As a result, fetch_code()'s 2nd parameter can then also become pointer-to-const.
2023-05-26x86: disassembling over-long insnsJan Beulich1-9/+10
The present way of dealing with them - misusing MAX_MNEM_SIZE, which has nothing to do with insn length - leads to inconsistent results. Since we allow for up to MAX_CODE_LENGTH - 1 prefix bytes (which then could be followed by another MAX_CODE_LENGTH "normal" insn bytes until we're done decoding), size the_buffer[] accordingly. Move struct dis_private down to be able to use MAX_CODE_LENGTH without moving its #define. While doing this also alter the order to have the potentially large array last.
2023-05-26x86: use fixed-width type for codep and friendsJan Beulich1-57/+55
This first of all removes a dependency on bfd_byte and unsigned char being the same types. It further eliminates the need to mask by 0xff when fetching values (which wasn't done fully consistently anyway), improving code legibility. While there, where possible add const.
2023-05-23Updated Swedish translation for the opcodes directoryNick Clifton2-238/+255
2023-05-23Support Intel FRED LKGSZhang, Jun7-4797/+4953
gas/ChangeLog: * NEWS: Support Intel FRED LKGS. * config/tc-i386.c: Add fred lkgs * doc/c-i386.texi: Document .fred, .lkgs. * testsuite/gas/i386/i386.exp: Add FRED LKGS tests * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. * testsuite/gas/i386/x86-64-fred.d: Ditto. * testsuite/gas/i386/x86-64-fred.s: Ditto. * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. * testsuite/gas/i386/x86-64-lkgs.d: Ditto. * testsuite/gas/i386/x86-64-lkgs.s: Ditto. opcodes/ChangeLog: * i386-dis.c: New entry for fred, lkgs. * i386-gen.c: Add CPU_FRED CPU_LKGS. * i386-init.h : Regenerated. * i386-mnem.h : Regenerated. * i386-opc.h: Add fred, lkgs. * i386-opc.tbl: Add FRED, LKGS instructions. * i386-tbl.h: Regenerated.
2023-05-23Revert "Support Intel FRED LKGS"liuhongt4-65/+2
This reverts commit e5a497fe38e0ab19e16bdd9e4b4ed5e4d0056478.
2023-05-23Support Intel FRED LKGSZhang, Jun4-2/+65
gas/ChangeLog: * NEWS: Support Intel FRED LKGS. * config/tc-i386.c: Add fred lkgs * doc/c-i386.texi: Document .fred, .lkgs. * testsuite/gas/i386/i386.exp: Add FRED LKGS tests * testsuite/gas/i386/x86-64-fred-intel.d: Ditto. * testsuite/gas/i386/x86-64-fred.d: Ditto. * testsuite/gas/i386/x86-64-fred.s: Ditto. * testsuite/gas/i386/x86-64-lkgs-intel.d: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.l: Ditto. * testsuite/gas/i386/x86-64-lkgs-inval.s: Ditto. * testsuite/gas/i386/x86-64-lkgs.d: Ditto. * testsuite/gas/i386/x86-64-lkgs.s: Ditto. opcodes/ChangeLog: * i386-dis.c: New entry for fred, lkgs. * i386-gen.c: Add CPU_FRED CPU_LKGS. * i386-init.h : Regenerated. * i386-mnem.h : Regenerated. * i386-opc.h: Add fred, lkgs. * i386-opc.tbl: Add FRED, LKGS instructions. * i386-tbl.h: Regenerated.
2023-05-19RISC-V: Minor improvements for dis-assembler.Nelson Chu3-21/+40
* Extract all private_data initializations into riscv_init_disasm_info, which called from print_insn_riscv rather than riscv_disassemble_insn. * The disassemble_free_target seems like the right place to release all target private_data, also including the internal data structures, like riscv_subsets. Therefore, add a new function, disassemble_free_riscv, to release them for safe. opcodes/ * disassemble.c (disassemble_free_target): Called disassemble_free_riscv for riscv to release private_data and internal data structures. * disassemble.h: Added extern disassemble_free_riscv. * riscv-dis.c (riscv_init_disasm_info): New function, used to init riscv_private_data. (riscv_disassemble_insn): Moved riscv_private_data initializations into riscv_init_disasm_info. (print_insn_riscv): Called riscv_init_disasm_info to init riscv_private_data once time. (disassemble_free_riscv): New function, used to free the internal data structures, like riscv_subsets.
2023-05-17gcc-4.5 build fixesAlan Modra1-14/+14
Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. bfd/ * elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun pointer. * elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat" variable to "status". gas/ * compress-debug.c (compress_finish): Supply all fields in ZSTD_inBuffer initialisation. include/ * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. opcodes/ * loongarch-opc.c: Supply all fields of zero struct initialisation in various opcode tables.
2023-05-12x86: move a few more disassembler helper functionsJan Beulich1-34/+29
... such that they wouldn't need forward declarations anymore. Note that append_seg() already was suitably placed.
2023-05-12x86: move get<N>() disassembler helper functionsJan Beulich1-75/+71
... such that none of them would need forward declarations anymore.
2023-04-28x86: limit data passed to i386_dis_printf()Jan Beulich1-22/+21
The function doesn't use "ins" for other than retrieving "info". Remove a thus pointless level of indirection.
2023-04-28x86: limit data passed to prefix_name()Jan Beulich1-8/+13
Make apparent that neither what "ins" points to nor, in particular, that "ins->info->private_data" is actually used in the function.
2023-04-28x86: rework AMX control insn disassemblyJan Beulich1-107/+50
Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth, and only then prefix, resulting in fewer table entries. Note that in the course of the re-work - TILEZERO has a previously missing decode step through rm_table[] added, - a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an infix).
2023-04-28x86: rework AMX multiplication insn disassemblyJan Beulich1-110/+42
Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth, and prefix last, resulting in fewer table entries. Note that in the course of the re-work wrong M_0 suffixes are also corrected to be M_1 (partly infixes now). Since it ended up confusing while testing the change, also adjust the test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).
2023-04-26 RISC-V: Support XVentanaCondOps extensionPhilipp Tomsich1-0/+4
Ventana Micro has published the specification for their XVentanaCondOps ("conditional ops") extension at https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf which contains two new instructions - vt.maskc - vt.maskcn that can be used in constructing branchless sequences for various conditional-arithmetic, conditional-logical, and conditional-select operations. To support such vendor-defined instructions in the mainline binutils, this change also adds a riscv_supported_vendor_x_ext secondary dispatch table (but also keeps the behaviour of allowing any unknow X-extension to be specified in addition to the known ones from this table). As discussed, this change already includes the planned/agreed future requirements for X-extensions (which are likely to be captured in the riscv-toolchain-conventions repository): - a public specification document is available (see above) and is referenced from the gas-documentation - the naming follows chapter 27 of the RISC-V ISA specification - instructions are prefixed by a vendor-prefix (vt for Ventana) to ensure that they neither conflict with future standard extensions nor clash with other vendors bfd/ChangeLog: * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext. (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS. gas/ChangeLog: * doc/c-riscv.texi: Add section to list custom extensions and their documentation URLs. * testsuite/gas/riscv/x-ventana-condops.d: New test. * testsuite/gas/riscv/x-ventana-condops.s: New test. include/ChangeLog: * opcode/riscv-opc.h Add vt.maskc and vt.maskcn. * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS. opcodes/ChangeLog: * riscv-opc.c: Add vt.maskc and vt.maskcn. Series-version: 1 Series-to: binutils@sourceware.org Series-cc: Kito Cheng <kito.cheng@sifive.com> Series-cc: Nelson Chu <nelson.chu@sifive.com> Series-cc: Greg Favor <gfavor@ventanamicro.com> Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
2023-04-26i386-dis.c UB shift and other tidiesAlan Modra1-94/+76
1) i386-dis.c:12055:11: runtime error: left shift of negative value -1 Bit twiddling is best done unsigned, due to UB on overflow of signed expressions. Fix this by using bfd_vma rather than bfd_signed_vma everywhere in i386-dis.c except print_displacement. 2) Return get32s and get16 value in a bfd_vma, reducing the need for temp variables. 3) Introduce get16s and get8s functions to simplify the code. 4) With some optimisation options gcc-13 legitimately complains about a fall-through in OP_I. Fix that. OP_I also doesn't need to use "mask" which was wrong for w_mode anyway. 5) Masking with & 0xffffffff is better than casting to unsigned. We don't know for sure that unsigned int is 32-bit. 6) We also don't know that unsigned char is 8 bits. Mask codep accesses everywhere. I don't expect binutils will work on anything other than an 8-bit char host, but if we are masking codep accesses in some places we might as well be consistent. (Better would be to use stdint.h types more in binutils.)
2023-04-24Revert "x86: work around compiler diagnosing dangling pointer"Alan Modra1-6/+0
This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.
2023-04-24gcc-13 i386-dis.c warningAlan Modra1-16/+31
opcodes/i386-dis.c: In function ‘print_insn’: opcodes/i386-dis.c:9865:22: error: storing the address of local variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=] * i386-dis.c (print_insn): Clear info->private_data before returning.
2023-04-24x86: work around compiler diagnosing dangling pointerJan Beulich1-0/+6
For quite come time print_insn() has been storing the address of a local variable into info->private_data. Since the compiler can't know that the field won't be accessed again after print_insn() returns, it may kind of legitimately diagnose this. And recent enough gcc does as of the introduction of the fetch_error() return paths (replacing setjmp()-based error handling). Utilizing that neither prefix_name() nor i386_dis_printf() actually use info->private_data, zap the pointer in fetch_error(), after having retrieved it for local use.
2023-04-21Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.cTom Tromey2-1/+6
A recent change in opcodes/i386-dis.c caused a build failure on my x86-64 Fedora 36 system, which uses: $ gcc --version gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4) [...] The error is: ../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’: ../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized] 12705 | disp = val & 0x8000 ? val - 0x10000 : val; | ~~~~^~~~~~~~ This patch fixes the warning. opcodes/ChangeLog 2023-04-21 Tom Tromey <tromey@adacore.com> * i386-dis.c (OP_J): Check result of get16.
2023-04-21x86: drop (explicit) BFD64 dependency from disassemblerJan Beulich1-13/+4
get64() is unreachable when !BFD64 (due to a check relatively early in print_insn()). Let's avoid the associated #ifdef-ary (or else we should extend it to remove more dead code).
2023-04-21x86: drop use of setjmp() from disassemblerJan Beulich1-5/+0
With the longjmp() uses all gone, the setjmp() isn't necessary anymore either.
2023-04-21x86: change fetch error handling for get<N>()Jan Beulich1-133/+114
Make them return boolean and convert FETCH_DATA() uses to fetch_code(). With this no further users of FETCH_DATA() remain, so the macro and its backing function are dropped as well. Leave value types as they were for the helper functions, even if I don't think that beyond get64() use of bfd_{,signed_}vma is really necessary. With type change of "disp" in OP_E_memory(), change the 2nd parameter of print_displacement() to a signed type as well, though (eliminating the need for a local variable of signed type). This also eliminates the need for custom printing of '-' in Intel syntax displacement expressions. While there drop forward declarations which aren't really needed.
2023-04-21x86: change fetch error handling when processing operandsJan Beulich1-233/+276
Make the handler functions all return boolean and convert FETCH_DATA() uses to fetch_code().
2023-04-21x86: change fetch error handling in get_valid_dis386()Jan Beulich1-30/+26
Introduce a special error indicator node, for the sole (real) caller to recognize and act upon.
2023-04-21x86: change fetch error handling in ckprefix()Jan Beulich1-12/+20
Use a tristate (enum) return value type to be able to express all three cases which are of interest to the (sole) caller. This also allows doing away with the abuse of "rex_used".
2023-04-21x86: change fetch error handling in top-level functionJan Beulich1-13/+59
... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch error handling is problematic, as per https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start using more conventional error handling instead. Also introduce a fetch_modrm() helper, for subsequent re-use.
2023-04-21x86: move fetch error handling into a helper functionJan Beulich1-28/+35
... such that it can be used from other than the setjmp() error handling path. Since I'd like the function's parameter to be pointer-to-const, two other functions need respective constification then, too (along with needing to be forward-declared).
2023-04-18RISC-V: Cache the latest mapping symbol and its boundary.Kito Cheng1-0/+43
This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188 Current flow: 1) Scan any mapping symbol less than this instruciton. 2) If not found, did a backward search. The flow seems not big issue, let run an example here: $x: 0x0 a <--- Found at step 1 0x4 b <--- Not found in step 1, but found at step 2 0x8 c <--- Not found in step 1, but found at step 2 $d 0x12 .word 1234 <-- Found at step 1 The instruciton didn't have the same address with mapping symbol will still did backward search again and again. So the new flow is: 1) Use the last mapping symbol status if the address is still within the range of the current mapping symbol. 2) Scan any mapping symbol less than this instruciton. 3) If not found, did a backward search. 4) If a proper mapping symbol is found in either step 2 or 3, find its boundary, and cache that. Use the same example to run the new flow again: $x: 0x0 a <--- Found at step 2, the boundary is 0x12 0x4 b <--- Cache hit at step 1, within the boundary. 0x8 c <--- Cache hit at step 1, within the boundary. $d 0x12 .word 1234 <-- Found at step 2, the boundary is the end of section. The disassemble time of the test cases has been reduced from ~20 minutes to ~4 seconds. opcode/ChangeLog PR 30282 * riscv-dis.c (last_map_symbol_boundary): New. (last_map_state): New. (last_map_section): New. (riscv_search_mapping_symbol): Cache the result of latest mapping symbol.
2023-04-12arc: remove faulty instructionsClaudiu Zissulescu2-720/+6
Clean not implemented ARC instruction from ARC instruction table.
2023-04-11Fix illegal memory access when disassembling corrupt NFP binaries.Nick Clifton2-1/+9
PR 30310 * nfp-dis.c (init_nfp6000_priv): Check that the output section exists.
2023-04-07Support Intel AMX-COMPLEXHaochen Jiang7-4711/+4808
gas/ChangeLog: * NEWS: Support Intel AMX-COMPLEX. * config/tc-i386.c: Add amx_complex. * doc/c-i386.texi: Document .amx_complex. * testsuite/gas/i386/i386.exp: Run AMX-COMPLEX tests. * testsuite/gas/i386/amx-complex-inval.l: New test. * testsuite/gas/i386/amx-complex-inval.s: Ditto. * testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto. * testsuite/gas/i386/x86-64-amx-complex-bad.s: Ditto. * testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto. * testsuite/gas/i386/x86-64-amx-complex.d: Ditto. * testsuite/gas/i386/x86-64-amx-complex.s: Ditto. opcodes/ChangeLog: * i386-dis.c (MOD_VEX_0F386C_X86_64_W_0): New. (PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0): Ditto. (X86_64_VEX_0F386C): Ditto. (VEX_LEN_0F386C_X86_64_W_0_M_1): Ditto. (VEX_W_0F386C_X86_64): Ditto. (mod_table): Add MOD_VEX_0F386C_X86_64_W_0. (prefix_table): Add PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0. (x86_64_table): Add X86_64_VEX_0F386C. (vex_len_table): Add VEX_LEN_0F386C_X86_64_W_0_M_1. (vex_w_table): Add VEX_W_0F386C_X86_64. * i386-gen.c (cpu_flag_init): Add CPU_AMX_COMPLEX_FLAGS and CPU_ANY_AMX_COMPLEX_FLAGS. * i386-init.h: Regenerated. * i386-mnem.h: Ditto. * i386-opc.h (CpuAMX_COMPLEX): New. (i386_cpu_flags): Add cpuamx_complex. * i386-opc.tbl: Add AMX-COMPLEX instructions. * i386-tbl.h: Regenerated.
2023-04-03asan: csky floatformat_to_double uninitialised valueAlan Modra1-10/+6
* csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't access ibytes after read_memory_func error. Change type of ibytes to avoid casts.
2023-04-03opcodes/arm: adjust whitespace in cpsie instructionAndrew Burgess1-2/+2
While I was working on the disassembler styling for ARM I noticed that the whitespace in the cpsie instruction was inconsistent with most of the other ARM disassembly output, the disassembly for cpsie looks like this: cpsie if,#10 notice there's no space before the '#10' immediate, most other ARM instructions have a space before each operand. This commit updates the disassembler to add the missing space, and updates the tests I found that tested this instruction.
2023-03-31RISC-V: Allocate "various" operand typeTsukasa OI2-8/+24
This commit intends to move operands that require very special handling or operand types that are so minor (e.g. only useful on a few instructions) under "W". I also intend this "W" to be "temporary" operand storage until we can find good two character (or less) operand type. In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved to "Wif" because of its special handling (and allocating single character "f" for this operand type seemed too much). Current expected allocation guideline is as follows: 1. 'W' 2. The most closely related single-letter extension in lowercase (strongly recommended but not mandatory) 3. Identify operand type The author currently plans to allocate following three-character operand types (for operands including instructions from unratified extensions). 1. "Wif" ('Zicbop': fetch offset) 2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions) 3. "Wfm" / "WfM" 'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling solely for widening conversion instructions. gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from "f" to "Wif". opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Move from "f" to "Wif". * riscv-opc.c (riscv_opcodes): Reflect new operand type.