aboutsummaryrefslogtreecommitdiff
path: root/gas
AgeCommit message (Collapse)AuthorFilesLines
2025-06-24RISC-V: Update Profiles string in RV23.Jiawei2-2/+2
Update the Profiles string in RV23 to include the extensions 'b' and 'supm'. bfd/ChangeLog: * elfxx-riscv.c: Update Profiles string in RV23. gas/ChangeLog: * testsuite/gas/riscv/attribute-19.d: Update test string. * testsuite/gas/riscv/attribute-20.d: Ditto.
2025-06-24gas/NEWS: Updated for RISC-VNelson Chu1-2/+4
2025-06-20aarch64: Support 2024 Debug Architecture system registers.Srinath Parvathaneni9-0/+149
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
2025-06-19aarch64: Support for FEAT_LSFEEzra Sitorus7-0/+916
FEAT_LSFE - Large System Float Extension - implements A64 base atomic floating-point in-memory instructions.
2025-06-19aarch64: Support for FEAT_SVE_F16F32MM, FEAT_F8F16M, FEAT_F8F32MMEzra Sitorus22-0/+209
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.
2025-06-19aarch64: Support for FEAT_CMPBREzra Sitorus13-2/+1788
FEAT_CMPBR - Compare and branch instructions. This patch adds these instructions: - CB<CC> (register) - CB<CC> (immediate) - CBH<CC> - CBB<CC> where CC is one of the following: - EQ - NE - GT - GE - LT - LE - HI - HS - LO - LS
2025-06-19aarch64: Add occmo flag for FEAT_OCCMOEzra Sitorus6-14/+25
FEAT_OCCMO support was introduced, but the feature flags were missing. This patch adds these flags, as well as splitting up the tests to test occmo vs occmo+memtag operands.
2025-06-19aarch64: Support for FEAT_SVE_BFSCALEEzra Sitorus12-2/+260
FEAT_SVE_BFSCALE introduces the SVE BFSCALE instruction, when the PE is not in Streaming SVE mode. If FEAT_SME2 is implemented, FEAT_SVE_BFSCALE also introduces SME multi-vector Z-targeting BFloat16 scaling instructions, BFSCALE and BFMUL.
2025-06-13x86: don't constrain %axl/%cxlJan Beulich7-35/+17
They can be used like their %al/%cl counterparts everywhere else; there's no apparent reason why they shouldn't be usable as accumulator / shift count respectively. Enforcing such a restriction only makes writing heavily macro-ized code more cumbersome.
2025-06-13x86: swap operands in OUT-with-immediate templateJan Beulich1-33/+33
In a number of places we assume that immediates come first in the set of operands. It is mere luck that so far OUT, having operands the other way around, wasn't negatively impacted by this. Leverage this to have a few loops start from the first non-immediate operand (or in one case to stop there). Note, however, that process_immext() inserts an immediate last, so especially all output_*() functions cannot be changed in the same way.
2025-06-13x86: refine UD<n> kind-of-insnsJan Beulich2-0/+6
While documentation of these continues to be lacking sufficient detail, it is becoming increasingly clear that in 66f1eba0b7e8 ("x86: correct UDn") I went too far with requiring operands, to populate a ModR/M byte. AMD hardware appears to always behave as indicated as "may" in PM 3.36, which for all practical purposes means there's no ModR/M byte. The SDM (rev 087) indicates that such behavior can occur on older hardware for UD0. Re-add an operand-less UD1 form (as well as its UD2B alias), while newly adding such a form also for UD0. Because of the ambiguity, there's no good/easy way of handling both possibilities in the disassembler, which hence remains unaltered. Further, from all information I'm able to gather, the 0F opcode space was only introduced with the i286; bump the minimal hardware requirement for all UD<n> accordingly.
2025-06-13gas: switch convert_to_bignum() to taking just an expressionJan Beulich1-7/+9
Both callers, despite spelling things differently, now pass the same input for its 2nd parameter. Therefore, as was supposed to be the case anyway, this 2nd parameter isn't needed anymore - the function can calculate "sign" all by itself from the incoming expression. Instead make the function return the resulting value, for emit_expr_with_reloc() to consume for setting its "extra_digit" local variable.
2025-06-13gas: also maintain signed-ness for O_big expressionsJan Beulich6-8/+36
Interestingly emit_leb128_expr() already assumes X_unsigned is properly set for O_big. Adjust its conversion-to-bignum to respect the incoming flag, and have convert_to_bignum() correctly set it on output. It further can't be quite right that convert_to_bignum() depends on anything other than the incoming expression. Therefore adjust emit_expr_with_reloc() to be in line with the other invocation. This also requires an adjustment for SH, which really should have been part of 762acf217c40 ("gas: maintain O_constant signedness in more cases").
2025-06-12aarch64: Add support for FEAT_FPRCVTRichard Ball4-0/+338
FEAT_FPRCVT introduces new versions of previous instructions. The instructions are used to convert between floating points and Integers. These new versions take as operands SIMD&FP registers for both the source and destination register. FEAT_FPRCVT also enables the use of some existing AdvSIMD instructions in streaming mode. However, no changes are needed in gas to support this.
2025-06-11arm: ignore inapplicable .arch=no...Jan Beulich1-2/+6
Unlike for command line options, where a base architecture needs to be provided explicitly, the .arch directive doesn't have such a requirement. Therefore it is odd that disabling of an inapplicable extension isn't silently ignored; claiming "not allowed for the current base architecture" is at best misleading. Alter the error path to emit a more "soft" diagnostic in that case instead.
2025-06-11aarch64: Add system registers for 2024 MPAM extensionYury Khrustalev7-0/+59
This patch adds support for new system registers introduced in the 2024 MPAM extension (Memory Partitioning and Monitoring): Available in Armv9.3-A: MPAMBW0_EL1, MPAMBW1_EL1, MPAMBW1_EL12, MPAMBW2_EL2, MPAMBW3_EL3, MPAMBWCAP_EL2, MPAMBWIDR_EL1 Available in Armv9.3-A with SME: MPAMBWSM_EL1 The details can be found in [1]. [1]: https://developer.arm.com/documentation/ddi0601/latest
2025-06-11gas md_apply_fix value castsAlan Modra11-22/+20
These are all innocuous but unneeded. pdp11 and ppc are only formatting.
2025-06-11gas md_apply_fix bad castsAlan Modra3-3/+3
ns32k and z8k cast a valueT pointer to a long pointer when loading md_apply_fix's value. That's quite wrong if the types have different sizes, as they may eg. on a 32-bit host with 64-bit bfd support. sparc also loads the value via a cast pointer, but at least in that case the cast is to the same size pointer. None of these casts are needed. Get rid of them.
2025-06-11loongarch gcc-4.5 build fixesAlan Modra3-18/+33
Yet another case of missing fields in struct initialisation, which I've replaced with a memset, and some complaints about identifiers shadowing global declarations. Fixing the shadowing in loongarch-parse.y is easy. This one isn't so easy: gas/expr.c: In function 'expr': gas/expr.c:1891:12: error: declaration of 'is_unsigned' shadows a global declaration include/opcode/loongarch.h:224:14: error: shadowed declaration is here opcode/loongarch.h declares lots of stuff that shouldn't be made available to generic gas code, so I've removed that header from tc-loongarch.h and moved the parts of TC_FORCE_RELOCATION_SUB_LOCAL and TC_FORCE_RELOCATION_SUB_LOCAL that need LARCH_opts to functions in tc-loongarch.c * config/loongarch-parse.y (loongarch_parse_expr): Rename param to avoid shadowing. * config/tc-loongarch.c (loongarch_assemble_INSNs): Use memset rather than struct initialisation. (loongarch_force_relocation_sub_local): New function. (loongarch_force_relocation_sub_same): Likewise. * config/tc-loongarch.h: Don't include opcode/loongarch.h. (loongarch_force_relocation_sub_local): Declare, and.. (TC_FORCE_RELOCATION_SUB_LOCAL): ..use here. (loongarch_force_relocation_sub_same): Declare, and.. (TC_FORCE_RELOCATION_SUB_SAME): ..use here.
2025-06-11kvx gcc-4.5 build fixesAlan Modra2-3/+3
More missing struct initialisers, for expressionS vars that in this case don't need to be initialised. Also an error: redefinition of typedef 'symbolS'. OK, so don't use a typedef.
2025-06-11csky gcc-4.5 build fixAlan Modra1-26/+50
gcc-4.5 warns about missing csky_cpus struct initialisers. Fix that by providing everything in the init macros and the zero sentinel, rather than just a single {0} as allowed by C99.
2025-06-11gas m68hc11 use standard qsort predicate signatureAlan Modra1-4/+4
Avoid a function cast when using cmp_opcode with qsort.
2025-06-11Re: Further rs_code_align support refinementAlan Modra1-9/+9
Don't write the repeating nop pattern if it won't be used for alpha handle_align too.
2025-06-11gas: xtensa build failure with --enable-64-bit-bfdAlan Modra1-7/+13
A 32-bit host with --enable-64-bit-bfd --target=xtensa-lx106-elf give: gas/config/tc-xtensa.c: In function ‘xg_get_best_chain_entry’: gas/config/tc-xtensa.c:7689:11: error: absolute value function ‘labs’ given an argument of type ‘offsetT’ {aka ‘long long int’} but has parameter of type ‘long int’ which may cause truncation of value [-Werror=absolute-value] 7689 | if (labs (off) >= J_RANGE - J_MARGIN) | ^~~~ Let's not use labs. Unlike labs vma_abs deliberately returns an unsigned value, and does the negation in an unsigned type so that signed overflow can't happen. * config/tc-xtensa.c (vma_abs): New function. (xg_get_best_chain_entry, xg_get_fulcrum, xg_find_best_trampoline), (xg_is_relaxable_fixup): Use in place of labs.
2025-06-10RISC-V: Add Smrnmi extension imply relation.Jiawei2-0/+2
This patch adds the dependency of Smrnmi extension on Zicsr extension. bfd/ChangeLog: * elfxx-riscv.c: New imply. gas/ChangeLog: * testsuite/gas/riscv/imply.d: New test check. * testsuite/gas/riscv/imply.s: New imply test. Signed-off-by: Jiawei <jiawei@iscas.ac.cn>
2025-06-10RISC-V: Add support for svvptc extension.Dongyan Chen2-1/+2
This implements the svvptc extensons, version 1.0[1]. [1] https://github.com/riscv/riscv-svvptc bfd/ChangeLog: * elfxx-riscv.c: New extension. gas/ChangeLog: * NEWS: Updated. * testsuite/gas/riscv/march-help.l: Ditto.
2025-06-09change some listing.c variables to unsigned.Alan Modra3-16/+16
The values are unsigned, and changing the types allows some casts to be removed.
2025-06-09dwarf2dbg.c line_entry.next assertAlan Modra1-7/+15
I was puzzling over how it was correct to cast what is clearly a struct line_entry** pointer to a struct line_entry* pointer for a few moments, and was going to write a comment but then decided we really don't require the "next" pointer to be where it is. Replace the assert with an inline function that does any necessary pointer adjustments. * dwarf2dbg.c (line_entry.next): Delete static assertion. (line_entry_at_tail): New inline function. (dwarf2_gen_line_info_1, dwarf2_finish): Replace casts in set_or_check_view arguments with line_entry_at_tail.
2025-06-09str_hash_find castsAlan Modra53-259/+195
Putting an explicit cast on the void* return from str_hash_find isn't necessary and doesn't add much to code clarity. In other cases, poor choice of function parameter types, eg. "void *value" in tc-aarch64.c checked_hash_insert rather than "const void *value" leads to needing (void *) casts all over the place just to cast away const. Fix that by correcting the parameter type. (And it really is a const, the function and str_hash_insert don't modify the strings.) This patch also removes some unnecessary casts in hash.c
2025-06-09str_hash_find_intAlan Modra8-174/+145
This changes the internal representation of string_tuple.value from a void* to an intptr_t, removing any concerns that code wanting to store an integer value will use values that are trap encodings or suchlike for a pointer. The ISO C standard says any void* can be converted to intptr_t and back again and will compare equal to the original pointer. It does *not* say any intptr_t can be converted to void* and back again to get the original integer.. Two new functions, str_hash_find_int and str_hash_insert_int are provided for handling integer values. str_hash_find_int returns (intptr_t) -1 on failing to find the key string. Most target code need minimal changes to use the new interface, but some simplification is possible since now a zero can be stored and differentiated from the NULL "can't find" return. (Yes, that means (intptr_t) -1 can't be stored.) I've changed the avr_no_sreg_hash dummy value to zero, and the loongarch register numbers don't need to be incremented. loongarch also doesn't need to store an empty key string (if it ever did).
2025-06-09metag build errorAlan Modra1-5/+4
gas/config/tc-metag.c: In function ‘parse_dsp_addr’: gas/config/tc-metag.c:4386:29: error: ‘regs[0]’ may be used uninitialized [-Werror=maybe-uninitialized] 4386 | if (!is_addr_unit (regs[0]->unit) && | ~~~~~~~^~~~~~ It looks like regs_read can be zero with "l" non-NULL, so this gcc complaint is accurate. * config/tc-metag.c (parse_dsp_addr, parse_dget_set): Check regs_read.
2025-06-06x86/Solaris: cope with new HANDLE_ALIGN behaviorJan Beulich1-1/+1
Extend the expectation adjustments done by 83d94ae428b1 ("tidy x86 HANDLE_ALIGN") to the Solaris clone of an affected testcase.
2025-06-04aarch64: Support id_aa64fpfr0_el1, id_aa64pfr2_el1Dmitry Chestnykh2-0/+4
2025-06-01weakref gas internal errorAlan Modra1-0/+1
This horrible testcase (cleaned up from oss-fuzz) r=x*2 x=r-r .weakref r,x r=r-5 triggers resolve_symbol_value "gas_assert (final_val == 0)" in weakref handling. * read.c (assign_symbol): Clear weakrefr.
2025-05-30elf symbol sizeAlan Modra10-111/+43
This changes elf_obj_sy.size from being malloc'd to being on the notes obstack. That means no code needs to free these expressions, which in turn means that the size expression can be shared when cloning symbols. Nothing modifies the size expressions except when resolving. In all cases I could see, if the size changes the entire expression is replaced. The patch also extracts code from elf_copy_symbol_attributes into a separate function for use by riscv and aarch64. * config/obj-elf.c (elf_obj_symbol_clone_hook): Delete. (elf_copy_symbol_size): New function, extracted and modified from.. (elf_copy_symbol_attributes): ..here. (obj_elf_size): Don't free size and use notes_alloc. (elf_frob_symbol): Don't free size. (elf_format_ops): Zero symbol_clone_hook. * config/obj-elf.h (elf_obj_symbol_clone_hook): Delete. (obj_symbol_clone_hook): Don't define. (elf_copy_symbol_size): Declare. * config/tc-aarch64.c (aarch64_elf_copy_symbol_attributes): Delete. * config/tc-aarch64.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as elf_copy_symbol_size. * config/tc-alpha.c (s_alpha_end): notes_alloc symbol size exp. * config/tc-ia64.c (dot_endp): Likewise. * config/tc-kvx.c (kvx_endp): Likewise. * config/tc-mips.c (s_mips_end): Likewise. * config/tc-riscv.c (riscv_elf_copy_symbol_attributes): Delete. * config/tc-riscv.h (OBJ_COPY_SYMBOL_ATTRIBUTES): Define as elf_copy_symbol_size.
2025-05-30gas symbol_removeAlan Modra1-41/+18
If a symbol is at the start of the symbol chain then symbol_rootP points at the symbol and symbol->x->previous is NULL. Testing either condition is sufficient, there is no need to test both. Similarly for the symbol at the end of the symbol chain. I'm testing the previous/next pointer because it's most likely that the symbol is not at the start/finish of the chain and thus we need to use that pointer. * symbols.c (symbol_remove): Tidy list handling. (symbol_append, symbol_clone, symbol_insert): Likewise.
2025-05-30Reduce rs_align_code memory for small alignmentsAlan Modra28-36/+61
On x86, MAX_MEM_FOR_RS_ALIGN_CODE is 35, when the most common alignment is 2**3 or 2**4, where the max memory required for the alignment nops is 7 and 15 bytes respectively. So there is some memory wasted since commit 83d94ae428b1. It's not a large amount, especially considering that frag overhead on x86_46 is 144 bytes, but even so I'd rather not be blamed for increasing gas memory usage. So to reduce the memory we'd like to take the alignment into consideration when initialising an rs_align_code frag. The only difficulty here is start_bundle making an rs_align_code frag with an alignment of zero initially, then later increasing the alignment. We change that to use the bundle alignment when setting up the frag. I think that is sufficient as bundle_align_p2 can't change in the middle of a start_bundle/finish_bundle sequence. I haven't modified any targets other than x86 in this patch. Most won't benefit much due to using fairly small MAX_MEM_FOR_RS_ALIGN_CODE. * read.c (start_bundle): Create rs_align_code frag with bundle_align_p2 alignment, then set to zero alignment. (finish_bundle): Adjust comment. * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Pass p2align and max to macro. * config/tc-i386.h (HANDLE_ALIGN): Assert that max_bytes is sufficient for nop padding. (max_mem_for_rs_align_code): New inline function. (MAX_MEM_FOR_RS_ALIGN_CODE): Use it. * config/tc-aarch64.h: Adjust MAX_MEM_FOR_RS_ALIGN_CODE. * config/tc-alpha.h: Likewise. * config/tc-arc.h: Likewise. * config/tc-arm.h: Likewise. * config/tc-epiphany.h: Likewise. * config/tc-frv.h: Likewise. * config/tc-ia64.h: Likewise. * config/tc-kvx.h: Likewise. * config/tc-loongarch.h: Likewise. * config/tc-m32r.h: Likewise. * config/tc-metag.h: Likewise. * config/tc-mips.h: Likewise. * config/tc-nds32.h: Likewise. * config/tc-ppc.h: Likewise. * config/tc-riscv.h: Likewise. * config/tc-rl78.h: Likewise. * config/tc-rx.h: Likewise. * config/tc-score.h: Likewise. * config/tc-sh.h: Likewise. * config/tc-sparc.h: Likewise. * config/tc-spu.h: Likewise. * config/tc-tilegx.h: Likewise. * config/tc-tilepro.h: Likewise. * config/tc-visium.h: Likewise. * config/tc-xtensa.h: Likewise.
2025-05-28Further rs_code_align support refinementAlan Modra7-17/+39
Don't write the repeating nop pattern if it won't be used.
2025-05-28PR 33029 segv in dwarf2_finish with --gdwarf-5Alan Modra1-2/+6
Specifying --gdwarf-5 with a source lacking a ".file 0" directive results in this segfault. * dwarf2dbg.c (out_debug_str): Use files[1] if files[0] is empty regardless of dwarf level.
2025-05-26gas: sframe: handle .cfi_same_valueIndu Bhagat4-3/+93
Fix PR gas/32953 - sframe: incorrect handling of .cfi_same_value in gas As per documentation, .cfi_same_value indicates that the current value of register is the same like in the previous frame, i.e. no restoration needed. gas/ * gen-sframe.c (sframe_xlate_do_same_value): New definition. (sframe_do_cfi_insn): Handle DW_CFA_same_value. gas/testsuite/ * gas/cfi-sframe/cfi-sframe.exp: Add new tests. * gas/cfi-sframe/cfi-sframe-common-11.d: New test. * gas/cfi-sframe/cfi-sframe-common-11.s: New test.
2025-05-23RISC-V: Add support for RISC-V Profiles 23.Jiawei2-0/+12
This patch adds support for RISC-V RVA23 and RVB23 Profiles[1]. [1] https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified bfd/ChangeLog: * elfxx-riscv.c: New profiles. gas/ChangeLog: * testsuite/gas/riscv/attribute-19.d: New test. * testsuite/gas/riscv/attribute-20.d: New test.
2025-05-23RISC-V: Add support for RISC-V Profiles 20/22.Jiawei8-7/+30
This patch introduces support for RISC-V Profiles RV20 and RV22 [1], enabling developers to utilize these profiles through the -march option. [1] https://github.com/riscv/riscv-profiles/releases/tag/v1.0 bfd/ChangeLog: * elfxx-riscv.c (struct riscv_profiles): New struct. (riscv_parse_extensions): New argument. (riscv_find_profiles): New checking function. (riscv_parse_subset): Add Profiles handler. gas/ChangeLog: * NEWS: Add RISC-V Profiles. * doc/as.texi: Update -march input type. * doc/c-riscv.texi: Ditto. * testsuite/gas/riscv/option-arch-fail.l: Modify hint info. * testsuite/gas/riscv/attribute-17.d: New test. * testsuite/gas/riscv/attribute-18.d: New test. * testsuite/gas/riscv/march-fail-rvi20u64v.d: New test. * testsuite/gas/riscv/march-fail-rvi20u64v.l: New test.
2025-05-23rs_fill_nop and md_generate_nopsAlan Modra6-61/+25
Make rs_fill_nop behave like rs_fill in using a repeat count (fr_offset) to emit fr_var length repeated nop patterns. Besides being more elegant, this reduces memory required for large .nops directives. * as.h (rs_fill_nop): Update comment. * config/tc-i386.c (i386_generate_nops): Handle rs_fill_nop as for rs_align_code. * config/tc-i386.h (MAX_MEM_FOR_RS_SPACE_NOP): Define. * listing.c (calc_hex): Handle rs_fill_nop as for rs_fill. * read.c (MAX_MEM_FOR_RS_SPACE_NOP): Define. (s_nops): Use MAX_MEM_FOR_RS_SPACE_NOP setting up frag. * write.c (write_contents): Call md_generate_nops for rs_fill_nop before the fr_fix part is written, so that rs_fill_nop can be handled as for rs_fill.
2025-05-23Re: gas .align limitAlan Modra2-8/+2
Now that rs_align_code has been corrected for all targets, put the .align limit back to bits_per_address-1. Also fix a comment. * frags.h (fr_var): Correct comment. * read.c (TC_ALIGN_LIMIT): Revert commit ff4c03516c change.
2025-05-23tidy x86 HANDLE_ALIGNAlan Modra39-2342/+2326
Reduce memory requirement for .align in code. I've changed some of the tests to use "clc" rather than "nop", so that code emitted by .p2align can be clearly seen. * config/tc-i386.c (i386_output_nops): Merge into.. (i386_generate_nops): ..here. Put shorter nop first. For rs_align_code make use of the fact that the last fr_var bytes are output repeatedly rather than repeating them here. * config/tc-i386.h (HANDLE_ALIGN): Don't test max_bytes. (MAX_MEM_FOR_RS_ALIGN_CODE): Update. * testsuite/gas/i386/nops-1.s, * testsuite/gas/i386/nops-2.s, * testsuite/gas/i386/nops-3.s, * testsuite/gas/i386/nops-4.s, * testsuite/gas/i386/nops16-1.s: Replace "nop" with "clc". * testsuite/gas/i386/align-branch-6.d, * testsuite/gas/i386/nop-1-suffix.d, * testsuite/gas/i386/nop-1.d, * testsuite/gas/i386/nop-1.l, * testsuite/gas/i386/nop-2.d, * testsuite/gas/i386/nop-4.d, * testsuite/gas/i386/nop-5.d, * testsuite/gas/i386/nops-1-core2.d, * testsuite/gas/i386/nops-1.d, * testsuite/gas/i386/nops-10.d, * testsuite/gas/i386/nops-2.d, * testsuite/gas/i386/nops-3.d, * testsuite/gas/i386/nops-4.d, * testsuite/gas/i386/nops-4a-i686.d, * testsuite/gas/i386/nops-5.d, * testsuite/gas/i386/nops-6.d, * testsuite/gas/i386/nops-7.d, * testsuite/gas/i386/nops-9.d, * testsuite/gas/i386/nops16-1.d, * testsuite/gas/i386/x86-64-align-branch-6.d, * testsuite/gas/i386/x86-64-nop-1.d, * testsuite/gas/i386/x86-64-nop-5.d, * testsuite/gas/i386/x86-64-nops-1-core2.d, * testsuite/gas/i386/x86-64-nops-1-pentium.d, * testsuite/gas/i386/x86-64-nops-1.d, * testsuite/gas/i386/x86-64-nops-2.d, * testsuite/gas/i386/x86-64-nops-3.d, * testsuite/gas/i386/x86-64-nops-4-core2.d, * testsuite/gas/i386/x86-64-nops-4.d, * testsuite/gas/i386/x86-64-nops-5.d, * testsuite/gas/i386/x86-64-nops-6.d, * testsuite/gas/i386/x86-64-nops-7.d: Adjust to suit.
2025-05-23tidy target HANDLE_ALIGNAlan Modra23-202/+106
avr, kvx, metag, mn10300, nds32, v850, visium, and wasm32 targets defined HANDLE_ALIGN without defining MAX_MEM_FOR_RS_ALIGN_CODE. This can result in a rather large chunk of memory being allocated. Fix that by a combination of changing the default allocation to one byte and/or defining a target MAX_MEM_FOR_RS_ALIGN_CODE. arm wanted to write out the entire set of nops, and limited allowed code alignment to 64 bytes to prevent large memory allocations. Fix that by making use of the fact that rs_align_code frags repeat fr_var bytes at fr_literal + fr_fix to fill out the required area. Fix metag, nds32 and kvx too, which it seems copied either arm or x86 in similarly not making use of repeating patterns. It's worth mentioning that my tidy to kvx changed the order of nop bundles, placing a short bundle first rather than last. epiphany was totally broken in that uninitialised data was written out for any alignment requiring more than three bytes of fill. ppc created a new frag to handle a branch over a large number of nops. This saves 4 bytes per rs_align_code frag, and most times the branch isn't used so it is generally a win for memory usage, but I figured the extra code complexity wasn't worth it. So that code of mine goes. visium copied the same scheme, so that goes too. This leaves x86 as the only target making large allocations for alignment frags. * frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Default to 1. * config/tc-aarch64.c (aarch64_handle_align): Remove always true condition. * config/tc-aarch64.h (MAX_MEM_FOR_RS_ALIGN_CODE): Move to be adjacent to HANDLE_ALIGN define. * config/tc-arm.c (arm_handle_align): Allow alignment of more than MAX_MEM_FOR_RS_ALIGN_CODE bytes. Just write one repeat of nop pattern to frag. (arm_frag_align_code): Delete function. * config/tc-arm.h (MAX_MEM_ALIGNMENT_BYTES): Don't define. (MAX_MEM_FOR_RS_ALIGN_CODE): Set to 7. (md_do_align): Don't define. (arm_frag_align_code): Don't declare. * config/tc-epiphany.c (epiphany_handle_align): Correct frag so that nop_pattern repeats rather than random data. * config/tc-epiphany.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-kvx.c (kvx_make_nops): Merge into.. (kvx_handle_align): ..here. Put short nop bundle first, followed by repeated full nop bundle. * config/tc-kvx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-m32c.h (HANDLE_ALIGN, MAX_MEM_FOR_RS_ALIGN_CODE): Don't define. * config/tc-metag.c (metag_handle_align): Just write one repeat of nop pattern to frag. * config/tc-metag.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-nds32.c (nds32_handle_align): Just write one repeat of nop pattern to frag. * config/tc-nds32.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-ppc.c (ppc_handle_align): Don't make a new frag for branch. * config/tc-ppc.h (MAX_MEM_FOR_RS_ALIGN_CODE): Increase to 8. * config/tc-visium.c (visium_handle_align): Don't make a new frag for branch. * config/tc-visium.h (MAX_MEM_FOR_RS_ALIGN_CODE): Define. * config/tc-wasm32.h (HANDLE_ALIGN): Don't define. * testsuite/gas/epiphany/nop.d, * testsuite/gas/epiphany/nop.s: New test. * testsuite/gas/epiphany/allinsn.exp: Run it. * testsuite/gas/kvx/nop-align.d: Adjust.
2025-05-22RISC-V: Add support for Smcdeleg and Ssccfg extensions.Jiawei14-1/+38
This patch rebases the original patch from Nelson's implement[1]. Added new extension Smcdeleg and Ssccfg with a new CSR, scountinhibit.[2] Co-Authored-By: Nelson Chu <nelson@rivosinc.com> Co-Authored-By: Jiawei Chen <jiawei@iscas.ac.cn> [1] https://patchwork.sourceware.org/project/binutils/patch/20240620045359.47513-1-nelson@rivosinc.com/ [2] https://github.com/riscvarchive/riscv-smcdeleg-ssccfg/releases/tag/v1.0.0 bfd/ChangeLog: * elfxx-riscv.c: New extensions. gas/ChangeLog: * NEWS: Mention new extensions. * config/tc-riscv.c (enum riscv_csr_class): New CSR class. (riscv_csr_address): Add support for Ssccfg. * testsuite/gas/riscv/csr-version-1p10.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p10.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p11.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p11.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p12.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p12.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p13.d: New test for Ssccfg CSR. * testsuite/gas/riscv/csr-version-1p13.l: New warning for Ssccfg CSR. * testsuite/gas/riscv/csr.s: New Ssccfg CSR. * testsuite/gas/riscv/imply.d: New imply check. * testsuite/gas/riscv/imply.s: New implies. * testsuite/gas/riscv/march-help.l: New helping info. include/ChangeLog: * opcode/riscv-opc.h (CSR_SCOUNTINHIBIT): New CSR address. (DECLARE_CSR): Add Ssccfg CSR.
2025-05-22LoongArch: Warning about incorrect 3rd argument of .alignLulu Cai3-2/+13
344b1e0f5f7 Introduced range-check 3rd argument of .align, incorrect value are not converted silently. added warning message to fix regression.
2025-05-22ubsan: integer overflow in tc-i386.c:offset_in_rangeAlan Modra1-1/+1
or $9223372036854775808,%eax runtime error: negation of -9223372036854775808 cannot be represented in type 'offsetT' (aka 'long'); cast to an unsigned type to negate this value to itself * config/tc-i386.c (offset_in_range): Avoid signed overflow.
2025-05-19ubsan: integer overflow in s_fillAlan Modra1-4/+4
Silence ubsan warning. We don't worry about wrap-around in most places that adjust abs_section_offset, so don't fuss over an overflow in the multiplication here. * read.c (s_fill): Replace "long" vars with offsetT and valueT. Avoid signed overflow calculating abs_section_offset.
generated by cgit v1.1 at 2025-09-18 21:47:46 +0000