https://gcc.gnu.org/g:cb2b5471516c3c469f65d927a2a30eb15357e429
commit r16-2049-gcb2b5471516c3c469f65d927a2a30eb15357e429 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Mon Jul 7 09:10:37 2025 +0100 aarch64: Fix ZIP1 order in aarch64_expand_vector_init [PR118891] aarch64_expand_vector_init contains some divide-and-conquer code that tries to load the odd and even elements into 64-bit registers and then ZIP them together. On big-endian targets, the even elements are more significant than the odd elements and so should come second in the ZIP. This fixes many execution failures on aarch64_be-elf, including gcc.c-torture/execute/pr28982a.c. gcc/ PR target/118891 * config/aarch64/aarch64.cc (aarch64_expand_vector_init): Fix the ZIP1 operand order for big-endian targets. Diff: --- gcc/config/aarch64/aarch64.cc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index f3ce3a15b095..0b4cd17c0ef9 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -24830,6 +24830,13 @@ aarch64_expand_vector_init (rtx target, rtx vals) emit_insn (rec_seq); } + /* The two halves should (by induction) be individually endian-correct. + However, in the memory layout provided by VALS, the nth element of + HALVES[0] comes immediately before the nth element HALVES[1]. + This means that, on big-endian targets, the nth element of HALVES[0] + is more significant than the nth element HALVES[1]. */ + if (BYTES_BIG_ENDIAN) + std::swap (halves[0], halves[1]); rtvec v = gen_rtvec (2, halves[0], halves[1]); rtx_insn *zip1_insn = emit_set_insn (target, gen_rtx_UNSPEC (mode, v, UNSPEC_ZIP1));