Re: [PATCH] wwwdocs: Note that old reload is deprecated

[Richard Biener via Gcc-patches]

> Am 11.01.2023 um 19:34 schrieb Segher Boessenkool 
> <seg...@kernel.crashing.org>:
> 
> 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.

Like if they cannot even build their target libraries aka their build will 
fail.  It would be nice to identify those and, say, make at least -mlra 
available to all ports that currently do not have a way to enable LRA?

Richard 

> 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