From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joseph Myers Subject: Re: RFC: remove the "tile" architecture from glibc Date: Fri, 9 Mar 2018 16:31:36 +0000 Message-ID: References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <20180307181407.GA24350@alf.mars> <9a60ac70-21e4-3f48-5cd7-ffd3aabc5c21@physik.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org In-Reply-To: <9a60ac70-21e4-3f48-5cd7-ffd3aabc5c21@physik.fu-berlin.de> To: John Paul Adrian Glaubitz Cc: Arnd Bergmann , Helmut Grohne , GNU C Library , linux-arch , metcalf@alum.mit.edu, Henrik Grindal Bakken , Linux Kernel Mailing List List-Id: linux-arch.vger.kernel.org On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote: > I have personally invested a lot of work into the SH port over the > past three years in Debian and I was involved fixing many bugs > and as a result, the port is quite usable. It would be really > disappointing to see it being removed all of a sudden :(. Note that SH glibc test results need some work - there are a large number of failures listed at . Probably most could be addressed with the NaN fixes I outlined at - but that does of course need someone to do the work to implement that in GCC and glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't seem very specific on this, but the existing setting was definitely determined by testing on hardware. SH experts with access to a range of different hardware may be needed to advise on what different hardware does or is supposed to do in this regard.) The glibc port whose test results cause me the most concern that it's effectively unmaintained and should be considered for obsoletion is MicroBlaze - the results are clearly a big mess (not something where one fix would probably resolve most failures as on SH) and there's no sign of activity to sort them out (nor has there been such activity for a long time). -- Joseph S. Myers joseph@codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay1.mentorg.com ([192.94.38.131]:64066 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbeCIQbn (ORCPT ); Fri, 9 Mar 2018 11:31:43 -0500 Date: Fri, 9 Mar 2018 16:31:36 +0000 From: Joseph Myers Subject: Re: RFC: remove the "tile" architecture from glibc In-Reply-To: <9a60ac70-21e4-3f48-5cd7-ffd3aabc5c21@physik.fu-berlin.de> Message-ID: References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <20180307181407.GA24350@alf.mars> <9a60ac70-21e4-3f48-5cd7-ffd3aabc5c21@physik.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-arch-owner@vger.kernel.org List-ID: To: John Paul Adrian Glaubitz Cc: Arnd Bergmann , Helmut Grohne , GNU C Library , linux-arch , metcalf@alum.mit.edu, Henrik Grindal Bakken , Linux Kernel Mailing List Message-ID: <20180309163136.hSRrEFLI9ES_W5t7z67U4A3YByFheY1k3k5ExLHnvK4@z> On Thu, 8 Mar 2018, John Paul Adrian Glaubitz wrote: > I have personally invested a lot of work into the SH port over the > past three years in Debian and I was involved fixing many bugs > and as a result, the port is quite usable. It would be really > disappointing to see it being removed all of a sudden :(. Note that SH glibc test results need some work - there are a large number of failures listed at . Probably most could be addressed with the NaN fixes I outlined at - but that does of course need someone to do the work to implement that in GCC and glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't seem very specific on this, but the existing setting was definitely determined by testing on hardware. SH experts with access to a range of different hardware may be needed to advise on what different hardware does or is supposed to do in this regard.) The glibc port whose test results cause me the most concern that it's effectively unmaintained and should be considered for obsoletion is MicroBlaze - the results are clearly a big mess (not something where one fix would probably resolve most failures as on SH) and there's no sign of activity to sort them out (nor has there been such activity for a long time). -- Joseph S. Myers joseph@codesourcery.com