Re: RFC: remove the "tile" architecture from glibc

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 1 Dec 2017, John Paul Adrian Glaubitz wrote:

> But why should it be only up to Mellanox whether support for Tile is
> part of glibc or not. I find straight up removal a bit too strong,
> especially since QEMU supports Tile as well. I think the first step
> should just be to mark the Tile port of glibc as unmaintained but not
> remove it altogether. That could be too frustrating for people using
> it. I'm pretty sure that there are more than just Mellanox' customers
> who are using Linux on Tile.

In practice, we need people with architecture expertise to resolve 
questions that arise about an architecture and review 
architecture-specific patches, and to run the tests before every release 
during the release freeze period and fix issues found so the release is in 
good shape for that architecture.

SH is unmaintained; no test results posted for 2.26.  TILEPro hasn't had 
results posted for a long time, and TILE-Gx didn't have results posted for 
2.26.  The maintained state of MicroBlaze (email to maintainer bounced the 
last time I tried, test results in very poor shape) and IA64 
(libm-test-ulps patch from September still not committed, no results 
posted for 2.26) is questionable.  I'd consider all of ia64 microblaze sh 
tilegx tilepro as candidates for obsoletion in the absence of active 
maintainers.  People are of course welcome to volunteer as maintainers, 
but they do need to keep up with maintainer responsibilities (testing for 
each release and fixing any major issues and regenerating ulps if 
necessary, reviewing patches, answering questions about 
architecture-specific issues).

> > If there is any desire to continue to support the tile architecture in
> > glibc, I'm happy to hand off to someone else as maintainer.  I'm aware
> > of one issue in the current code, which is that upstream gcc vector
> > insn support has a bug in it that causes some of the string functions
> > to misbehave; I can publish a fix for that before handing off, if desired.
> 
> Yes, that would be great. If it's a known bug and there is a known,
> working fix, it would be great if it could be merged upstream and
> Tile support be kept for a while for the people hacking on Debian
> on Tile.

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.)

-- 
Joseph S. Myers
joseph@codesourcery.com