On 7/9/25 8:00 AM, Richard Sandiford wrote:
Makes me wonder if I should resurrect my aarch64_be RFS. I changed how
those systems worked in the system a few years back to make it work
better with container based testing rather than direct chroots. I never
converted aarch64_be to that setup. It shouldn't be hard if you think
it's valuable.
I'm not sure TBH. The only reason I started looking at aarch64_be
recently was to test a patch for Konstantinos. And it turns out that
the "before" results are really, really poor. I think that suggests
that no-one on the AArch64 side is testing big-endian regularly.
(And LLVM have got away without ever implementing big-endian arm_sve.h
support.) So there's a danger that you'd spend a lot of your time
triaging AArch64-specific bugs. There again, like you say...
It's certainly not a clear cut decision. I do test some BE stuff (m68k,
s390x, H8 and a few others), but certainly nothing BE with scalable
vectors. And yes, I definitely found it useful to test those BE things
for Konstantinos, and CRCs and ext-dce, etc. The gap I see is BE with
scalable vectors.
Unfortunately any data I had on stability of aarch64_be has been lost in
the years since I did the conversion. I don't recall spending much time
on it and it was one of the slower things to test via qemu, so it just
didn't seem worth the effort at the time.
The best solution would be to discover that someone has an aarch64_be
setup working on a RPI. But I don't see any evidence of that anywhere.
I can't think of another system where we'd these kinds of issues.
...it probably does have some "unique" features. :)
I later came across another instance of the subreg_lsb thing, which was
causing other ICEs. I went ahead and installed this as obvious, given
the approval for the earlier one.
Tested on aarch64-linux-gnu and aarch64_be-elf.
Yea, definitely OK. Thanks.
jeff
