From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12418 invoked by alias); 1 Dec 2017 22:41:01 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 12408 invoked by uid 89); 1 Dec 2017 22:41:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=guy, Hx-languages-length:2109 X-HELO: relay1.mentorg.com Date: Fri, 01 Dec 2017 22:41:00 -0000 From: Joseph Myers To: John Paul Adrian Glaubitz CC: Chris Metcalf , GNU C Library Subject: Re: RFC: remove the "tile" architecture from glibc In-Reply-To: <995aac59-2f9d-2a6a-2b5c-b827410ad295@physik.fu-berlin.de> Message-ID: References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <995aac59-2f9d-2a6a-2b5c-b827410ad295@physik.fu-berlin.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) X-SW-Source: 2017-12/txt/msg00044.txt.bz2 On Fri, 1 Dec 2017, John Paul Adrian Glaubitz wrote: > > SH is unmaintained; no test results posted for 2.26. > > I will be happy to provide these results. Adhemerval has also access to one of We need someone to fix any major issues that show up in the results, as well as running the tests and posting the results on the wiki page during each release freeze. > my SH porterboxes. Also, SH is actually being redeveloped as an open > source architecture called J-Core (http://j-core.org/) and they're working > on releasing new, SH-compatible open source hardware over the next years. > I already have J2 board at home, compatible SH-2. SH-2 isn't relevant to glibc (SH-4 would be). > There is also a guy within Debian currently working on ia64 who started > recently. Don't know what the current status is though. Well, we need a maintainer to review and commit patches (like the routine libm-test-ulps patch that was posted but has not been committed). > > Someone will need to convert Tile GCC to use LRA instead of reload if that > > GCC port is to avoid obsoletion when reload is obsoleted. (CC0 obsoletion > > may be sooner, but I think the only glibc port that would imply obsoleting > > is m68k; all other glibc ports have non-CC0 GCC ports, but several don't > > use LRA.) > > If m68k support is dropped, I'm either jumping out of the window or I'm > becoming a shepheard or something. Linux/m68k is one of *the* most popular > retro-platforms we have in Linux and there are lots of people in- and outside > Debian working on it. The kernel is still actively maintained on m68k with > at least four active maintainers that I know. If you want to keep m68k support in GCC, moving the port away from cc0 (and then to LRA) is necessary. The timescale suggested in was that cc0 ports could be deprecated for GCC 8 and removed for GCC 9 if not converted. See for a guide to converting GCC ports away from cc0. -- Joseph S. Myers joseph@codesourcery.com