Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit
rounding is not that useful because we currently have rounding feature
directly on E-core now and no need to use 256-bit rounding as somehow
a workaround. This patch will remove all the support and backport to
Binutils 2.44.
gas/ChangeLog:
* NEWS: Mention support removal.
* config/tc-i386.c (build_evex_prefix): Remove U bit encode.
(check_VecOperands): Remove ymm check for rounding.
(s_insn): Revise .insn comment.
* testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm
rounding related test.
* testsuite/gas/i386/avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/evex.d: Ditto.
* testsuite/gas/i386/evex.s: Ditto.
* testsuite/gas/i386/i386.exp: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-evex.d: Ditto.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.l: Removed.
* testsuite/gas/i386/avx10_2-rounding-inval.s: Removed.
* testsuite/gas/i386/avx10_2-rounding.d: Removed.
* testsuite/gas/i386/avx10_2-rounding.s: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed.
* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed.
opcodes/ChangeLog:
* i386-dis.c (struct instr_info): Remove U bit.
(get_valid_dis386): Roll back to APX condition.
* i386-opc.tbl: Remove ymm rounding support.
* i386-tbl.h: Regenerated.
FEAT_MEC support was introduced in [1]. However, the dc instruction was
missing these encodings:
- DC CIPAE
- DC CIGDPAE
Furthermore, the Arm ARM states that FEAT_MEC is an optional extension,
introduced for v9.2-a.
Therefore, these sysregs:
- MECIDR_EL2
- MECID_P0_EL2
- MECID_A0_EL2
- MECID_P1_EL2
- MECID_A1_EL2
- VMECID_P_EL2
- VMECID_A_EL2
- MECID_RL_A_EL3
which were introduced in that commit now require -march=armv9.2-a at the very
least to be enabled, as well as the dc encodings.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae".
* aarch64-sys-regs.def: Add V8_7A as a requirement for the above system
registers.
gas/testsuite/gas/ChangeLog
* aarch64/mec-invalid.s: Add .arch directive.
* aarch64/mec.d: Add .arch directive and check for cipae, cigdpae.
* aarch64/mec.s: Add MEC data cache operations test.
* aarch64/mec-arch-bad.d: New test to check for bad arch version.
* aarch64/mec-arch-bad.l: Above.
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3
Regression tested on aarch64-none-elf
The original observation was that STILP is warned about when everything
is fine. Documentation, not just for STILP, says explicitly that
behavior is identical to respective pre-existing insns (for STILP in
particular that's STP). With that it's unclear why distinct logic was
added: Other code can be re-used, simply distinguishing by the number of
operands. This was diagnostics also end up more consistent.
Along with adding some STILP uses to the (positive) testcase, also add a
pair of STLR to similarly demonstrate that the register overlap goes
without warning when there's no write-back.
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds the additional extension "XTheadVdot" based on the
"V" extension, and it provides four 8-bit multiply and add with
32-bit instructions for the "v" extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([2]).
Co-Authored-By: Lifang Xia <lifang_xia@linux.alibaba.com>
[1] https://github.com/XUANTIE-RV/thead-extension-spec/tree/master/xtheadvdot
[2] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add support
for "XTheadVdot" extension.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* doc/c-riscv.texi: Likewise.
* testsuite/gas/riscv/march-help.l: Likewise.
* testsuite/gas/riscv/x-thead-vdot.d: New test.
* testsuite/gas/riscv/x-thead-vdot.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_TH_VMAQA_VV): New.
* opcode/riscv.h (enum riscv_insn_class): Add insn class for
XTheadVdot.
opcodes/ChangeLog:
* riscv-opc.c: Likewise.
Some DW_CFA_* and DW_OP_* take wider than byte, but non-LEB128 operands.
Having to hand-encode such when needing to resort to .cfi_escape isn't
very helpful.
These are data generating directives not overly different from e.g.
.byte and .long. Whatever (directly) results from should also be
represented in the listing, if one was requested. It's just that the
output data is generated much later than the parsing of the directive
arguments.
Ignoring return values often isn't a good idea. The Sparc assembler in
particular would report an internal error if an expression with
relocation specifier is used with .cfi_escape, when the same works fine
with .byte. Propagate the relocation indicator up from
do_parse_cons_expression(), and eventually into emit_expr_with_reloc().
dot_cfi_fde_data(), only retaining the expression's X_add_number, would
require further work. Simply report the lack of support there. While
there, also check that what we were dealt is actually a constant.
PR gas/32721
In this bogus piece of code distilled from fuzzing and slightly edited:
A=%eax|%!
Y=A
Z=A
or $6,Z
the first of the equates with A on the rhs changes A's section (due to
the use of S_GET_VALUE()), from expression to register, thus yielding Y
in the expression section (and X_op being O_symbol), but Z in the
register section (and X_op being O_register with X_add_value being -1).
There shouldn't be random O_register expressions, though, for targets
setting md_register_arithmetic to false. Plus both Y and Z would better
be exchangeable.
In pseudo_set() wire handling of O_symbol expressions referencing a
symbol in the expression section to that of other stuff ending up in
this section.
Also avoid bogus O_register expressions to be created, for targets
setting md_register_arithmetic to false: S_GET_VALUE() would resolve
any arithmetic, which must not happen for such targets. To be on the
safe side for such targets, also amend resolve_register(). Correct
another earlier oversight there too (affecting at least Z80), by using
the new expr_copy() helper there as well.
Undo 46b9f07dfe79 ("PR 32721, internal error in
tc-i386.c:parse_register"), albeit without losing the simplification it
did.
The mapping symbol "$x" without an ISA string "means using ISA
configuration from ELF attribute."[1]. Currently the code does not
reset the subset_list. This means that a previous mapping symbol that
overrides the ISA string will continue to be used, rather than the
default string set in the ELF file's .riscv.attributes section. This
can cause incorrect or failed instruction decodings.
In practice, this causes problems when disassembling code generated by
LLVM, which (unlike gas) does not emit explicit mapping symbols at the
start of each section.
This change stores the default architecture string seen at the beginning
of disassembly in the global parse data struct, and restores that to
subset_list whenever a bare "$x" symbol is seen.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol
Before this patch, the mapping-x.s was dumped as,
00000000 <.text>:
0: 00000013 nop
4: 0001 .insn 2, 0x0001
6: 0001 .insn 2, 0x0001
Which is caused by the definiation of $x was conflict with the psABI.
The psABI defined $x to the architecture which is same as the file elf
attribute. But GNU defined it to that is same as the previous $x<isa>,
and always generated $x<isa> at the begining of each section. That is
because considering two objects have different architecture in their elf
attributes, then $x will always be wrong after linking since the merged
arch string will be changed. For example, object A with rv32ic and object
B with rv32ia, $x from A is rv32ic and $x from B is rv32ia, but the final
output is rv32ica, so $x from A and B need to be updated to rv32ic and
rv32ia by linker respectively. I think let linker to do this is not good,
so in order to follow the psABI, we will stop generating the $x for now.
Instead, all $x will be replaced with the corresponding $x<isa>. The
dis-assembler will also treat $x like what psABI defined.
CFI_escape is most commonly used to include DWARF expressions in the
unwind information. One may also use CFI_escape to add OS-specific CFI
opcodes. Up until now, SFrame generation process would skip generating
SFrame FDE at the mere sight of a CFI_escape opcode.
Fine tune the handling of CFI_escape for SFrame generation by explicitly
checking for few "harmless" (in context of SFrame generation)
CFI_escape DWARF info:
- DW_CFA_expression affecting registers of no significance to SFrame
stack trace info
- DW_CFA_value_offset affecting registers of no significance to SFrame
stack trace info
Expose the current cfi_escape_data structure in dw2gencfi.c to the
relevant header file to allow SFrame generation APIs to use it too.
Valid unwind info may be split across multiple .cfi_escape directives.
Conversely, it is also allowed to simply put multiple DWARF expressions
and/or operations in a single .cfi_escape directive. Handling all of
these cases correctly will need parsing/processing that is not deemed
worth the effort in context of SFrame generation; We continue to skip
generating SFrame FDE for these cases and warn the user.
In future, SFrame stack trace format may support non-SP/FP as base
register (albeit in limited form). Add an explicit check in
sframe_xlate_do_escape_expr (to test against the current CFA register)
to ensure the functionality continues to work.
Use differentiated warning text in sframe_xlate_do_val_offset to avoid
confusion to the user as the same function is used for handling
.cfi_val_offset and .cfi_escape DW_CFA_val_offset,...
Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64
and aarch64 (and s390x too).
gas/
* gas/dw2gencfi.c (struct cfi_escape_data): Move from ...
* gas/dw2gencfi.h (struct cfi_escape_data): ... to.
* gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string
for .cfi_escape conditionally.
(sframe_xlate_do_escape_expr): New definition.
(sframe_xlate_do_escape_val_offset): Likewise.
(sframe_xlate_do_cfi_escape): Likewise.
(sframe_do_cfi_insn): Handle CFI_escape explicitly.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-9.d: New test.
* gas/cfi-sframe/cfi-sframe-common-9.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test.
If data is encountered that is not a power of two, dump all of the data with
a .<N>byte directive. The current largest support risc-v instruction length
is 22, so the data over 22 bytes will be displayed by,
.insn, 22, ... + .<N-22>byte.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Add gpr and fpr names for the o64 ABI to objdump.
With the recent addition of both EABIs, this completes support for the
standard ABI options (ABI-breaking options such as -modd-spreg or
-mabi=32 -mfp64 notwithstanding). The names have been verified against
GCC's usage of the registers. Notably, the only(?) documentation that
defines the o64 ABI at
https://gcc.gnu.org/projects/mipso64-abi.html
appears to contain a mistake w.r.t. floating-point arguments. In
particular:
> If the first and second arguments floating-point arguments to a
> function are 32-bit values, they are passed in $f12 and $f14.
As from 4.0.0 this does not happen in GCC's implementation of the ABI;
a pair of single-float arguments are still passed in $f12 and $f13, the
same as when one or both of the arguments are double-precision floats.
The registers $f12, $f13 and $f14 have been named $fa0, $fa1 and $ft10
to match the implementation.
Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>
Extend gpr and fpr register names with names suitable for both EABIs.
Heavily inspired by the EABI documenation written by Eric Christopher,
which can be read at
https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html
2025-02-15 Anghelo Carvajal <angheloalf95@gmail.com>
* mips-dis.c (mips_fpr_names_eabi32): New variable.
(mips_fpr_names_eabi64): New variable.
(mips_abi_choices): Add "eabi32" and "eabi64" options.
Signed-off-by: Anghelo Carvajal <angheloalf95@gmail.com>
The MIPS ABI register names are the same between n64 and n32, so remove
duplication and use n64 GPR disassembly output for the n32 test as well.
The tests were developed long before we gained output reuse support.
Fix broken commit 070961b377b3 ("MIPS: Set r6 as default arch if vendor
is img") that sets up GAS in an inconsistent way where "img" vendor has
been used with a 64-bit configuration, such as `mips64-img-linux-gnu'.
In that case GAS is set up to use a 64-bit ABI by default combined with
the MIPS32r6 CPU, which is 32-bit.
Consequently GAS always fails to assemble even trivial input, producing
a message such as:
Assembler messages:
Error: -march=mips32r6 is not compatible with the selected ABI
.../gas/testsuite/gas/all/nop.s:2: Error: `gp=32' used with a 64-bit ABI
unless the defaults have been suitably overridden either for the ABI or
the CPU.
Set the default CPU to MIPS64r6 for 64-bit "img" vendor configurations
then and adjust the GAS testsuite accordingly, removing 1048 FAIL and 3
ERROR regression test results for the `mips64-img-linux-gnu' and
`mips64el-img-linux-gnu' targets each.
Add support for giving negated targets in the list of targets passed to
`mips_arch_create' for the purpose of setting the default architecture.
This is so that a subset of targets can be excluded from matching within
a broader set of targets.
Updating should be based solely on the current instruction. For example,
recording of VEX-encoded insns as v3 should be independent of there
being earlier AMX insns.
Further for BASELINE only a very limited set of the
GNU_PROPERTY_X86_FEATURE_2_* bits should actually be taken into account:
Most of the bits represent advanced (later) features (XSAVE, XSAVEOPT,
and XSAVEC for example being part of v3).
In commit a0094f1a70e1 ("gas: make .nops output visible in listing") I
was wrongly assuming fr_fix would be zero for rs_fill_nop, when that's
only a side effect of listing_newline() inserting dummy frags, but only
when file/line did actually change from the previous invocation. This is
in particular not going to be true when the .nops directive isn't the
first statement on a line.
So far tricks had to be played to use .insn to encode extended-EVEX
insns; the X4 bit couldn't be controlled at all. Extend the syntax just
enough to cover all features, taking care to reject invalid feature
combinations (albeit aiming at being as lax there as possible, to offer
users as much flexibility as we can - we don't, after all, know what
future will bring).
In a pre-existing testcase replace all but one .byte; the one that needs
to remain wants to have EVEX.U clear in a way that's neither
controllable via AVX10/256 embedded rounding (would otherwise also set
EVEX.ND), nor via the index register (EVEX.X4), as there's no memory
operand. For one of the converted instances ModR/M.mod needs correcting:
An 8-bit displacement requires that to be 1, not 2. Also adjust source
comments to better represent what the bad insns mimic.
RISC-V already support bfloat16 instruciton like Zfbfmin, Zvfbfmin and
Zvfbfwma, so I think it's reasonable to add .bfloat16 directive to
support bfloat16 data type.
And the code logic mostly support by common code already.
There is inconsistency regarding whether or not +sme implies +sve2 and
whether +nosve2 implies +nosme. In particular, GCC 14 assumes the
dependency exists, and canonicalises target strings accordingly, whereas
LLVM treats the features as independent.
This patch removes the positive implication while retaining the negative
implication. This is the more permissive choice in each case, and
allows us to support target strings written with either interpretation
in mind.
This reduces our ability to detect invalid instructions, but we already
can't rely on this detection because gas doesn't know whether functions
might be executed in streaming mode and/or non-streaming mode.
The aarch64_feature_enable_set change is functionally redundant within
this patch. It is included because the longer term intention is to
instead remove the workaround in aarch64_parse_features, once the
internal feature checks have been modified to support having both
AARCH64_FEATURE_SME set and AARCH64_FEATURE_SVE unset.
Similarly, the dependency from +sme to +fp16 is currently redundant, but
this redundancy relies upon an incorrect dependency from +fcma to +fp16.
This can be fixed in the future, but it might require modifying internal
feature checks for a few FCMA instructions, so it's left unchanged for
now.
We agreed with LLVM that we shouldn't enforce the architectural
dependencies between fp8 muliplication features, so remove them.
Additionally, fix a typo in the gating for FEAT_SME_F8F16 instructions,
which were mistakenly gated by +sme-f8f32 instead. Until now this
mistake had been masked by the dependency between the features.
Like for RMPUPDATE documentation is about to change as far as operands
are concerned. They're merely the other way around here.
While adjustind gas documentation, also add the missing RMPQUERY
counterparts there.
AMD are about to update their doc, to help clarify that what we
currently do isn't quite right: In particular it is not %rax but %rcx
which is affected by address size. In fact, that's a normal memory
operand, just not expressed via ModR/M byte, but fixed to (%rcx) (or
(%ecx) with 32-bit addressing).
To support this in the assembler, generalize memory operand handling so
far specific to XLAT (which isn't really a string insn, but requires its
memory operand to be (%bx) / (%ebx) / (%rbx)).
In the disassembler mimic handling after XLAT's, too.
Printing implicit %ds: and %es: prefixes is pretty meaningless in 64-bit
mode. The SDM explicitly omits them for the 64-bit forms, and it
obviously has them for the other ones only to cover non-64-bit modes
(oddly enough the AMD PM has them present).
Do away with at least one of the limitations - all other targets permit
multiple values to be specified with a single directive. Re-arrange the
logic further to also overcome an internal error in
riscv_insert_uleb128_fixes(), as e.g. observed by the all/sleb128-2
testcase. This way there's also no need to parse expressions twice,
thus also not raising the same diagnostics (if any) twice.
Note how this addresses a pre-existing XFAIL (where the comment wasn't
really applicable either for RISC-V).
Also update documentation, also to mention that differences between
symbols may be used with .uleb128 (albeit I'm uncertain whether there
are limitations).
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore require vector index register operands to be specified in
assembler source. That is do require coding of D(VX,B) instead of
allowing to omit VX=0 as D(,B), D(B), or D. Emit an error message if
a mandatory vector index register is omitted:
Error: operand <n>: missing vector index register operand
Note that this change is not backwards compatible. But any code that
omitted the specification of the vector index register is likely to be
in error. Therefore it is favorable to report an error than to stay
backward compatible.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gas/
* config/tc-s390.c (md_gather_operands): Do not allow
vector index register operands to be optionally omitted.
gas/testsuite/
* gas/s390/zarch-base-index-0.d (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-base-index-0.s (vgef): Move tests with omitted
vector index register operands ...
* gas/s390/zarch-base-index-0-err.s (vgef): ... to here.
* gas/s390/zarch-base-index-0-err.l (vgef): Expect error
for omitted vector index register operands.
* gas/s390/zarch-omitted-base-index.d (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-omitted-base-index.s (vgef): Move tests with
omitted vector index register operands ...
* gas/s390/zarch-omitted-base-index-err.s (vgef): ... to here.
* gas/s390/zarch-omitted-base-index-err.l (vgef): Expect error
for omitted vector index register operands.
* gas/s390/zarch-warn-areg-zero.l (vgef): Remove tests with
omitted vector index register operands.
* gas/s390/zarch-warn-areg-zero.s (vgef): Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore when using s390-specific assembler option "-mwarn-areg-zero"
do not warn if vector index register 0 is specified.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gas/
* config/tc-s390.c (md_gather_operands): Do not warn about
vector index register 0.
gas/testsuite/
* gas/s390/zarch-warn-areg-zero.l (vgef): Do not expect warning
about vector index register 0.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Vector index registers are currently only used in the VRV instruction
format. Unlike general purpose index registers an operand value of
zero (e.g. %v0, 0, or omitted) does not imply a zero value:
"For VRV format instructions, a vector element is used in the formation
of the intermediate value. This vector element is an unsigned binary
integer value that is added to the base address and 12-bit displacement
to form a 64-bit intermediate sum. The vector element is designated by
a vector register and an element index. A zero V field accesses the
element in vector register zero and does not imply a zero value." [1]
Therefore do not omit vector index register 0 in disassembly, that is
disassemble D(VX,B) with VX=0 as D(VX,B) instead of D(B). Also do not
disassemble index register 0 as "0", that is disassemble D(VX,B) with
VX=0 as D(%v0,B) instead of D(0,B). Note that a base register 0 still
still gets disassembled as "0", that is D(VX,B) with B=0 disassembles
into D(VX,0).
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-dis.c (s390_print_insn_with_opcode): Do not omit vector
index register 0 in disassembly. Disassemble it as %v0.
gas/testsuite/
* gas/s390/zarch-base-index-0.d (vgef): Expect vector index
register 0 in disassembly.
* gas/s390/zarch-omitted-base-index.d (vgef): Likewise.
Suggested-by: Florian Krohm <flo2030@eich-krohm.de>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Simplify the .machine directive parsing logic, so that cpu_string is
always xstrdup'd and can therefore always be xfree'd before returning
to the caller.
This resolves the following memory leak reported by ASAN:
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x3ff8aafbb1d in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x2aa338861cf in xmalloc ../../libiberty/xmalloc.c:149
#2 0x2aa338868ff in xstrdup ../../libiberty/xstrdup.c:34
#3 0x2aa320253cb in s390_machine ../../gas/config/tc-s390.c:2172
#4 0x2aa31fddc7b in read_a_source_file ../../gas/read.c:1293
#5 0x2aa31f4f7bf in perform_an_assembly_pass ../../gas/as.c:1223
#6 0x2aa31f4f7bf in main ../../gas/as.c:1436
#7 0x3ff8a02be35 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x3ff8a02bf33 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x2aa31f5758f (/home/jremus/git/binutils/build-asan/gas/as-new+0x2d5758f) (BuildId: ...)
While at it add tests with double quoted .machine
"<cpu>[+<extension>...]" values.
gas/
* config/tc-s390.c (s390_machine): Simplify parsing and free
cpu_string before returning.
gas/testsuite/
* gas/s390/machine-parsing-1.l: Add tests with double quoted
values.
* gas/s390/machine-parsing-1.s: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
PR gas/32579
The deprecated .s (swapped operand encoding) functionality got in the
way of properly recognizing this specific form. Move the Solaris-
specific code ahead of that.
On casual reading of older gcc configure scripts it might be supposed
that the test for gas string merge support tries with %progbits after
a fail on ARM with @progbits. It doesn't succeed due to a bug. So to
support building of older gcc's for ARM without users having to edit
gcc sources, add a hack to gas. The hack can disappear in a few years
when building older gcc's likely requires other work too.
I've changed the docs to reflect what we actually allow for .section
syntax prior to this patch. (No way should this hack be documented as
allowed!)
PR 32491
* config/obj-elf.c (obj_elf_section): Allow missing entsize
for ARM gcc configure bug.
* doc/as.texi: Correct syntax of ELF .section directive.
* testsuite/gas/elf/string.s,
* testsuite/gas/elf/string.d: Test it.
Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
declared with "S" (SHF_STRING) to specify the entity size, but then
would warn if the entity size was omitted, as with the old syntax.
Unfortunately, since specifying the entity size is incompatible with
binutils 2.43 or earlier, this makes it impossible to specify a
strings section in source code without generating an assembly warning
(the new syntax isn't supported in older assemblers and the old syntax
generates warnings).
Nevertheless, the old code was wrong in that it did not set the entity
size at all, in contravention of the ELF specification (though to date
there are no known cases where this mattered outside of mergeable
sections).
Fix this by permitting the original syntax without a warning again,
but by defaulting the entity size to 1. This is compatible with the
most common case of strings being byte-based.
Added some tests for the various flavours of declaration that we
support.
Many FEAT_SVE2p1 instructions need to be enabled by either of two
different features (one for streaming mode, and one for non-streaming
mode). This patch adds correct gating conditions for these
instructions.
There were also a few sve2p1 instructions missing altogether, so add
those as well.
The testsuite is modified to check for all alternative enablement
conditions. In many cases this is done by adding an alternative
assembler commands to existing test files. For some SME/SME2 tests,
only some of the instructions are enabled by +sve2p1, so these are
copied into a separate test. For original SVE2p1 tests, the non-SME2p1
instructions have been moved to a separate test file.
There are also new tests for the newly added instructions. These
include a couple of fixme comments relating to bad error reporting,
which should be investigated later.
Deriving operand size may no longer assume 512-bit vector size when
embedded rounding is in use. In fact it was apparently wrong to do so
in the first place, as that's not correct for scalar insns. Drop the
rounding type check altogether; we fall back to EVEX.LIG when no
suitable operand was specified anyway, later in the function (and, btw,
similarly for VEX encodings).
