On Fri, Jul 4, 2025 at 9:15 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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. > > Tested on aarch64-linux-gnu & aarch64_be-elf. OK to install?
Ok. > > Richard > > > gcc/ > * config/aarch64/aarch64.cc (aarch64_expand_vector_init): Fix the > ZIP1 operand order for big-endian targets. > --- > 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 f3ce3a15b09..0b4cd17c0ef 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)); > -- > 2.43.0 >
