From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107719 invoked by alias); 4 Dec 2017 18:03:50 -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 107649 invoked by uid 89); 4 Dec 2017 18:03:50 -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,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=increasingly, Hx-languages-length:1747, conclusions X-HELO: relay1.mentorg.com Date: Mon, 04 Dec 2017 18:03:00 -0000 From: Joseph Myers To: Adhemerval Zanella CC: , John Paul Adrian Glaubitz Subject: Re: RFC: remove the "tile" architecture from glibc In-Reply-To: <15306eb4-759b-1dbf-d605-bfa62e9fdaf3@linaro.org> Message-ID: References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <995aac59-2f9d-2a6a-2b5c-b827410ad295@physik.fu-berlin.de> <1d4c3707-ff44-15b2-9eb4-ec5174e3f007@physik.fu-berlin.de> <15306eb4-759b-1dbf-d605-bfa62e9fdaf3@linaro.org> 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-02.mgc.mentorg.com (139.181.222.2) X-SW-Source: 2017-12/txt/msg00086.txt.bz2 On Mon, 4 Dec 2017, Adhemerval Zanella wrote: > GCC version which does not support m68k (I do not think we have a policy > to remove deprecated architecture in GCC latest version where there is still > compiler support in older releases). In my view, if GCC removes support for an architecture I think that's sufficient basis for obsoleting it in glibc as well rather than waiting a few more years in which it becomes increasingly hard for people to test changes build on that architecture because of the need to use a different GCC version there. However, we don't need to decide this now, as while there are suggestions of obsoleting non-cc0 or non-LRA architectures, nothing has happened yet in that regard (and even if non-cc0 architectures were obsoleted for GCC 8, the removal probably wouldn't be until after GCC 8 branched, so until then we'd just add --enable-obsolete to the GCC configure options for such architectures in build-many-glibcs.py). > Now back to thread topic, Chris Metcalf gave us some indications that > tilepro userbase and support do not justify the maintaining effort. It > already has kernel ABI incompatibilities (for instance ca768667d873 fix on > linux and some atomic unsupported operations that broke the build on > recent glibc fixes). I think we could at least remove old tilepro > support. Certainly we can come to separate conclusions about obsoletion for tilegx and tilepro. (Preferably obsoleting tilepro would mean the sysdeps directory structure then being simplified to avoid the unnecessary directory levels in tile/tilegx, just as after obsoleting ARM old-ABI I eliminated the eabi/ subdirectories.) -- Joseph S. Myers joseph@codesourcery.com