On Wed, Jan 11, 2023 at 05:27:36PM +0100, Richard Biener wrote: > > Am 11.01.2023 um 16:17 schrieb Segher Boessenkool > > <seg...@kernel.crashing.org>: > >> Note this is more info for port maintainers not for users and > >> changes.html is for users. > > > > And users will notice some ports will have to be removed, because those > > ports are not maintained / not maintained enough. Some ports will not > > work with LRA, most will be easy to fix, but someone will have to do > > that. If no one does so the port works sufficiently well it will have > > to be removed before release. > > > >> "In a future release" is also quite vague. > > > > It's what we usually say in changes.html . "In GCC 14" if you want? > > > > I can add some stuff on how this will benefit users? > > I guess listing the ports without LRA support might be a first step for > clarification?
Every port has LRA support. Some ports will not build later when we delete old reload, because they use some functions and/or data structures unique to that. But all that is easily fixed (for the port maintainers at least, assuming they understand what their code does ;-) ). The bigger problem is that if the port has never been tested with LRA the chances of it working in all cases are not great (say 50%), so likely some attention will be needed to get the compiler back to release quality. And some ports will even not work for the simplest pieces of source code. Those are the problematic cases. Usually not hard to fix -- all the more complicated targets already run LRA always, the hard work is done already -- but it still requires a target maintainer (with a suitable testing environment, hopefully even hardware) to do the work. This is what I want to alert people to, and get agreement that this will happen next major release. Segher
