> On Jan 11, 2023, at 1:32 PM, Segher Boessenkool <seg...@kernel.crashing.org>
> wrote:
>
> 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.
Or, as in my case, because building with LRA as the default triggers an ICE
that I don't understand. I posted a note to the GCC list about what I saw, but
have received no reaction.
If anyone can help me understand how LRA can generate RTL with register choices
that violate the constraints listed in the MD file, I would be grateful.
paul