From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 85F683858C83 for ; Wed, 11 Jan 2023 18:33:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 85F683858C83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 30BIWp6T001282; Wed, 11 Jan 2023 12:32:51 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 30BIWpt3001281; Wed, 11 Jan 2023 12:32:51 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 11 Jan 2023 12:32:51 -0600 From: Segher Boessenkool To: Richard Biener Cc: Gerald Pfeifer , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] wwwdocs: Note that old reload is deprecated Message-ID: <20230111183251.GV25951@gate.crashing.org> References: <20230111151520.GU25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jan 11, 2023 at 05:27:36PM +0100, Richard Biener wrote: > > Am 11.01.2023 um 16:17 schrieb Segher Boessenkool : > >> 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