From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58457 invoked by alias); 29 Sep 2015 14:00:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 58445 invoked by uid 89); 29 Sep 2015 14:00:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f173.google.com Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 29 Sep 2015 14:00:56 +0000 Received: by ykdg206 with SMTP id g206so7388075ykd.1 for ; Tue, 29 Sep 2015 07:00:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.197.211 with SMTP id o202mr21032533yke.27.1443535253953; Tue, 29 Sep 2015 07:00:53 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Tue, 29 Sep 2015 07:00:53 -0700 (PDT) In-Reply-To: <560A9488.9090405@redhat.com> References: <20150908.214115.1585933992134500164.davem@davemloft.net> <2D64499C-B66A-4873-BDB9-C6190FF539FE@comcast.net> <56089802.7010803@redhat.com> <560993B9.70105@redhat.com> <20150928202838.GA1401@gate.crashing.org> <1443532762.2509.134.camel@t-online.de> <560A9488.9090405@redhat.com> Date: Tue, 29 Sep 2015 14:31:00 -0000 Message-ID: Subject: Re: [PATCH] Convert SPARC to LRA From: Richard Biener To: Jeff Law Cc: Oleg Endo , Segher Boessenkool , Vladimir Makarov , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02213.txt.bz2 On Tue, Sep 29, 2015 at 3:39 PM, Jeff Law wrote: > On 09/29/2015 07:19 AM, Oleg Endo wrote: >> >> On Mon, 2015-09-28 at 15:28 -0500, Segher Boessenkool wrote: >> >>> We can at least change the default to LRA, so new ports get it unless >>> they like to hurt themselves. >>> >>> I don't think it makes sense to keep reload around *just* for the ports >>> that are in "maintenance mode": by the time we are down to *just* those >>> ports, it makes more sense to relabel them as "unmaintained". >> >> >> Just for my understanding ... what's the definition of "maintenance >> mode" or "unmaintained"? > > I'm not sure there's any formal definition. > > If the port isn't getting tested, bugs aren't getting fixed, fails to build, > etc then it's probably a good bet you could put it into the unmaintained > bucket. > > If the port does get occasional fixes (primarily driven by BZs), but not > getting updated on a regular basis (such as conversion to LRA, conversion to > RTL prologue/epilogue, etc), may be only getting occasional testing, etc. > Then it's probably fair to call it in maintenance mode. A great example > IMHO would be the m68k. Another criteria would be available hardware for which both the PA and alpha ports are a good example. When you can't buy new hardware then targets that could formerly host GCC quickly rot to the state where only cross-compilation is viable (and having "old" GCC is good enough). > I would say we probably have many ports in maintenance mode right now. Not > sure if any are in the unmaintained mode with perhaps the exception of > interix. I'd say that all ports not in maintainance mode should be at least secondary archs as we can expect maintainers to be around to keep it at the quality level we expect for secondary targets. Now I'd like to do the opposite conclusion and declare all non-primary/secondary targets as in maintainance mode ... ;) We have 49 targets (counting directories) and 7 of them compose the list of primary and secondary triplets. Richard. > jeff