This is the mail archive of the
mailing list for the glibc project.
Re: RFC: remove the "tile" architecture from glibc
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
> > 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
Joseph S. Myers