Automatic date update in version.in

arm: don't treat XScale features as part of the FPU [PR 28031]

Although the XScale and its iwMMX extensions are implemented in the
Arm co-processor space, they are not considered to be part of the FPU
specification.  In particular, they cannot be enabled or disabled via
a .fpu directive.  It's therefore incorrect to strip these properties
when a new .fpu directive is encountered.

Note that the legacy Maverick co-processor is considered to be a FPU
and it is possible to control this via the .fpu directive.

include:

PR gas/28031
* opcode/arm.h (FPU_ANY): Exclude XScale-related features.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Gas: Forgot to commit changelog

Arm: Fix forward thumb references [PR gas/25235]

When assembling a forward reference the symbol will be unknown and so during
do_t_adr we cannot set the thumb bit.  The bit it set so early to prevent
relaxations that are invalid. i.e. relaxing a Thumb2 to Thumb1 insn when the
symbol is Thumb.

But because it's done so early we miss the case for forward references.
This patch changes it so that we additionally check the thumb bit during the
internal relocation processing.

In principle we should be able to only set the bit during reloc processing but
that would require changes to the other relocations that the instruction could
be relaxed to.

This approach still allows early relaxations (which means that we have less
iteration of internal reloc processing) while still fixing the forward reference
case.

gas/ChangeLog:

2021-05-24  Tamar Christina  <tamar.christina@arm.com>

PR gas/25235
* config/tc-arm.c (md_convert_frag): Set LSB when Thumb symbol.
(relax_adr): Thumb symbols 4 bytes.
* testsuite/gas/arm/pr25235.d: New test.
* testsuite/gas/arm/pr25235.s: New test.

(cherry picked from commit d3e52e120b68bf19552743fbc078e0a759f48cb7)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

arm: Fix bugs with MVE vmov from two GPRs to vector lanes

The initial problem I wanted to fix here is that GAS was rejecting MVE
instructions such as:

vmov q3[2], q3[0], r2, r2

with:

Error: General purpose registers may not be the same -- `vmov q3[2],q3[0],r2,r2'

which is incorrect; such instructions are valid. Note that for moves in
the other direction, e.g.:

vmov r2, r2, q3[2], q3[0]

GAS is correct in rejecting this as it does not make sense to move both
lanes into the same register (the Arm ARM says this is CONSTRAINED
UNPREDICTABLE).

After fixing this issue, I added assembly/disassembly tests for these
vmovs. This revealed several disassembly issues, including incorrectly
marking the moves into vector lanes as UNPREDICTABLE, and disassembling
many of the vmovs as vector loads. These are now fixed.

Regtested on arm-eabi, no regressions.

OK for trunk? What about backports?

Thanks,
Alex

gas/ChangeLog:

* config/tc-arm.c (do_mve_mov): Only reject vmov if we're moving
into the same GPR twice.
* testsuite/gas/arm/mve-vmov-bad-2.l: Tweak error message.
* testsuite/gas/arm/mve-vmov-3.d: New test.
* testsuite/gas/arm/mve-vmov-3.s: New test.

opcodes/ChangeLog:

* arm-dis.c (mve_opcodes): Fix disassembly of
MVE_VMOV2_GP_TO_VEC_LANE when idx == 1.
(is_mve_encoding_conflict): MVE vector loads should not match
when P = W = 0.
(is_mve_unpredictable): It's not unpredictable to use the same
source register twice (for MVE_VMOV2_GP_TO_VEC_LANE).

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

PR27755, powerpc-ld infinite loop

PR 27755
* elf32-ppc.c (ppc_elf_inline_plt): Do increment rel in loop.

(cherry picked from commit 337d0bf887a3ed6b6b2123fecfec0736640edcaf)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix type of .persistent.bss section

The change implementing the .persistent family of sections broke the
existing support for the .persistent.bss section in the compiler:

int a __attribute__ ((section (".persistent.bss")));

t.s: Assembler messages:
t.s:4: Warning: setting incorrect section type for .persistent.bss

The compiler encodes it as @nobits but the assembler expects @progbits.
The assembler is incorrect and should treat the section like the compiler.

bfd/
* elf.c (special_sections_p): Add .persistent.bss.
gas/
* testsuite/gas/elf/section25.d: Run it everywhere.
* testsuite/gas/elf/section26.d: Likewise.
* testsuite/gas/elf/section26.s: Add test for .persistent.bss.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Make objcopy -p work when an output file is specified

More fallout from the PR27456 fixes.

PR 27456
* rename.c (smart_rename): When TO and FROM are equal, just set
file timestamp.
* objcopy.c (strip_main, copy_main): Always call smart_rename.

(cherry picked from commit d0ecdcddc363ad7f05fc50cf1eee4028fa7f8964)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

AArch64: Fix Diagnostic messaging for LD/ST Exclusive.

A summary of what this patch set fixes:

For instructions

STXR w0,x2,[x0]
STLXR w0,x2,[x0]

The warning we emit currently is misleading:

Warning: unpredictable: identical transfer and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical transfer and status registers --`stxr w0,x2,[x0]'

it ought to be:

Warning: unpredictable: identical base and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxr w0,x2,[x0]'

For instructions:

ldaxp x0,x0,[x0]
ldxp x0,x0,[x0]

The warning we emit is incorrect

Warning: unpredictable: identical transfer and status registers --`ldaxp x0,x0,[x0]'
Warning: unpredictable: identical transfer and status registers --`ldxp x0,x0,[x0]'

it ought to be:

Warning: unpredictable load of register pair -- `ldaxp x0,x0,[x0]'
Warning: unpredictable load of register pair -- `ldxp x0,x0,[x0]'

For instructions

stlxp   w0, x2, x2, [x0]
stxp    w0, x2, x2, [x0]

We don't emit any warning when it ought to be:

Warning: unpredictable: identical base and status registers --`stlxp w0,x2,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxp w0,x2,x2,[x0]'

gas/ChangeLog:

2021-04-09  Tejas Belagod  <tejas.belagod@arm.com>

* config/tc-aarch64.c (warn_unpredictable_ldst): Clean-up diagnostic messages
for LD/ST Exclusive instructions.
* testsuite/gas/aarch64/diagnostic.s: Add a diagnostic test for STLXP.
* testsuite/gas/aarch64/diagnostic.l: Fix-up test after message clean-up.

(cherry picked from commit dd17020328b4ebf45be26eed156fba3d269096f6)

AArch64: Fix Atomic LD64/ST64 classification.

Patch 1: Fix diagnostics for exclusive load/stores and reclassify
 Armv8.7-A ST/LD64 Atomics.

Following upstream pointing out some inconsistencies in diagnostics,

https://sourceware.org/pipermail/binutils/2021-February/115356.html

attached is a patch set that fixes the issues. I believe a combination
of two patches mainly contributed to these bugs:

https://sourceware.org/pipermail/binutils/2020-November/113961.html
https://sourceware.org/pipermail/binutils/2018-June/103322.html

A summary of what this patch set fixes:

For instructions

STXR w0,x2,[x0]
STLXR w0,x2,[x0]

The warning we emit currently is misleading:

Warning: unpredictable: identical transfer and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical transfer and status registers --`stxr w0,x2,[x0]'

it ought to be:

Warning: unpredictable: identical base and status registers --`stlxr w0,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxr w0,x2,[x0]'

For instructions:

ldaxp x0,x0,[x0]
ldxp x0,x0,[x0]

The warning we emit is incorrect

Warning: unpredictable: identical transfer and status registers --`ldaxp x0,x0,[x0]'
Warning: unpredictable: identical transfer and status registers --`ldxp x0,x0,[x0]'

it ought to be:

Warning: unpredictable load of register pair -- `ldaxp x0,x0,[x0]'
Warning: unpredictable load of register pair -- `ldxp x0,x0,[x0]'

For instructions

stlxp   w0, x2, x2, [x0]
stxp    w0, x2, x2, [x0]

We don't emit any warning when it ought to be:

Warning: unpredictable: identical base and status registers --`stlxp w0,x2,x2,[x0]'
Warning: unpredictable: identical base and status registers --`stxp w0,x2,x2,[x0]'

For instructions:

st64bv  x0, x2, [x0]
st64bv  x2, x0, [x0]

We incorrectly warn when its not necessary. This is because we classify them
incorrectly as ldstexcl when it should be lse_atomics in the opcode table.
The incorrect classification makes it pick up the warnings from warning on
exclusive load/stores.

Patch 2: Reclassify Armv8.7-A ST/LD64 Atomics.

This patch reclassifies ST64B{V,V0}, LD64B as lse_atomics rather than ldstexcl
according to their encoding class as specified in the architecture. This also
has the fortunate side-effect of spurious unpredictable warnings getting
eliminated.

For eg. For instruction:

st64bv  x0, x2, [x0]

We incorrectly warn when its not necessary:

Warning: unpredictable: identical transfer and status registers --`st64bv x0,x2,[x0]'

This is because we classify them incorrectly as ldstexcl when it should be
lse_atomics in the opcode table. The incorrect classification makes it pick
up the warnings from warning on exclusive load/stores. This patch fixes it
by reclassifying it and no warnings are issued for this instruction.

opcodes/ChangeLog:

2021-04-09  Tejas Belagod  <tejas.belagod@arm.com>

* aarch64-tbl.h (struct aarch64_opcode aarch64_opcode_table): Reclassify
LD64/ST64 instructions to lse_atomic instead of ldstexcl.

(cherry picked from commit 52efda8266cb1f8ade0193f45801fdd6e42165ac)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in