On Fri, 2 May 2025, Richard Biener wrote: > > All in all I do keep the switch to LRA in mind and maybe I'll be able to > > move forward in the GCC 16 development cycle after all, but all I can do > > is entirely in my free time and that seems to be very limited recently and > > plagued with emergencies to handle. > > I appreciate your work on those targets. It seems that both are in > a state where basic development and testing _of GCC_ can be done when > LRA is enabled? That means users can stick to GCC 15 which will be
As I say currently the Alpha target does not complete compilation[1] for the base non-BWX microarchitecture if switched to LRA, so between VAX and Alpha it will necessarily be the higher priority issue to fix. I only have non-BWX hardware and I'm not interested in decommissioning it or upgrading. There appear to be a few users around, but I seem to be the last GCC developer remaining who is willing to do anything about the port. It doesn't help that Alpha/QEMU appears broken and produces unreliable results, so it'd have to be someone with actual hardware (or willing to fix QEMU first). > supported for the next 3 years and avoid newer versions when the > issues affect them. There's always the hope that other interested > parties contribute fixes to GCC 16 and on to recover the loss taken > by removing reload, esp. if the ports itself do not end up 100% > broken. There seems to be continuous interest in the VAX backend from the NetBSD community, but again they're mostly users or kernel hackers rather than compiler developers. Also they appear reluctant to submit upstream their local changes for some reason, even though I did encourage them and I'd review and verify backend patches with my setup in my lab as required. NB I understand your position and the need to cut the line sometime, and I knew what the situation is with the VAX backend and that it would be manageable. In principle it might be that it's only that single ICE that needs debugging before we can claim LRA usable, even if poor RISC-like code results (FWIW the PDP-11 backend suffers from the same fate). As long as user code builds and runs we can improve code gen gradually. What I was not aware of is the situation with the Alpha backend and the need to put out fires there. That non-BWX issue with Linux kernel's RCU algorithms was a nasty surprise to me, one I could have dealt with before with less time pressure if I knew about it. And it is exactly the deprecation of old reload that I had in mind while working on a solution to avoid data races with sub-longword accesses[2][3] and insisting that it lands in GCC 15, exactly so that we have a working compiler release for Linux kernel requirements[4]. May I therefore please at least ask for the approval for the backport of this long overdue regression fix: <https://patchwork.sourceware.org/project/gcc/patch/alpine.deb.2.21.2502251934260.65...@angie.orcam.me.uk/> to GCC 15, so that users indeed have a way to move forward with non-BWX hardware until we have proper LRA support in the Alpha backend? As I say I'll prioritise it over VAX stuff given the current situation, but still I have so much to do and so little time (and personal life outside the lab too), so it feels at risk to me even though we're early in Stage 1. References: [1] "Bootstrap fails with ICE: in operator[], at vec.h:910 with LRA on non-BWX alpha", <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117185> [2] "Fix data races with sub-longword accesses on Alpha", <https://inbox.sourceware.org/gcc-patches/alpine.deb.2.21.2411141652300.9...@angie.orcam.me.uk/> [3] "Alpha: Data races with 8-bit/16-bit stores", <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117759> [4] "Alpha: Emulate unaligned LDx_L/STx_C for data consistency", <https://lore.kernel.org/r/CAHk-=wgbzk1ffoyitklnz4jne-eztysrztcyrrxzzxf8evk...@mail.gmail.com/> Maciej
