RFC: remove the "tile" architecture from glibc

RFC: remove the "tile" architecture from glibc

[Chris Metcalf]

The tile architecture was introduced to glibc in 2011 and first
appeared in glibc 2.15.  The chip family of TILEPro and TILE-Gx was
developed by Tilera, which was eventually acquired by Mellanox.  Now
at Mellanox we are developing new chips based on the ARM64
architecture; our last TILE-Gx chip (the Gx72) was released in 2013,
and our customers using the tile architecture products are now all in
maintenance mode, as far as we know, and not looking to upgrade their
software to newer open-source releases.

Compounding this state of affairs is the fact that after twelve years
here I am moving on next week; my last day at Mellanox is December
8th.  Since tracking upstream development of the old tile architecture
is not a high priority for Mellanox, reasonably enough, it seems
cleanest at this point to propose removal of the architecture from the
glibc tree, so that the 2.26 release will be the last release to have
tile support.

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.

I will in any case be dropping off the glibc list (other than perhaps
occasionally reading the archives) at the end of next week.  It's been
a rewarding experience following glibc's development over the last six
years and I will certainly miss being part of this community.

I'm keeping that libc.so.6 sticker I got from Carlos, though!  :)

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

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

[Joseph Myers]

Note that removal should include removing tile support from 
build-many-glibcs.py.  (There's no need to remove relocations from elf.h, 
which isn't restricted to currently-supported architectures.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[John Paul Adrian Glaubitz]

Hi Chris!

On 12/01/2017 10:34 PM, Chris Metcalf wrote:
> The tile architecture was introduced to glibc in 2011 and first
> appeared in glibc 2.15.  The chip family of TILEPro and TILE-Gx was
> developed by Tilera, which was eventually acquired by Mellanox.  Now
> at Mellanox we are developing new chips based on the ARM64
> architecture; our last TILE-Gx chip (the Gx72) was released in 2013,
> and our customers using the tile architecture products are now all in
> maintenance mode, as far as we know, and not looking to upgrade their
> software to newer open-source releases.

This feels very odd. It isn't been very long until I heard about TileGX
for the first time when I saw a talk by a Japanese Debian guy who showed
me his efforts to get Debian running on a small router with impressive
performance [1]. The board built gcc natively in just about two hours.

Tile has also been added to Debian Rebootstrap and it's currently possible
to bootstrap for this architecture from source. The Jenkins job shows
that this currently is successful.

> Compounding this state of affairs is the fact that after twelve years
> here I am moving on next week; my last day at Mellanox is December
> 8th.  Since tracking upstream development of the old tile architecture
> is not a high priority for Mellanox, reasonably enough, it seems
> cleanest at this point to propose removal of the architecture from the
> glibc tree, so that the 2.26 release will be the last release to have
> tile support.

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.

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

> I will in any case be dropping off the glibc list (other than perhaps
> occasionally reading the archives) at the end of next week.  It's been
> a rewarding experience following glibc's development over the last six
> years and I will certainly miss being part of this community.

And here I am just having joined the list, this being one of the first
things too read :/.

> I'm keeping that libc.so.6 sticker I got from Carlos, though!  :)

Adrian

> [1] https://mikrotik.com/product/CCR1009-7G-1C-1SplusPC
> [2] https://jenkins.debian.net/view/rebootstrap/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

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

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

[John Paul Adrian Glaubitz]

On 12/01/2017 11:11 PM, Joseph Myers 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.

Yes, I'm aware of that and we in Debian are trying to help in these cases
where ever we can. We have several porterboxes for powerpc*, sparc*, alpha,
hppa and more available for porters and we're happy to create accounts for
anyone from glibc upstream to test any changes. In fact, Adhemerval Zanella
is already one of these users.

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

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

There is also a guy within Debian currently working on ia64 who started
recently. Don't know what the current status is though.

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

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.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joseph Myers]

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 
<https://gcc.gnu.org/ml/gcc/2017-07/msg00231.html> was that cc0 ports 
could be deprecated for GCC 8 and removed for GCC 9 if not converted.  See 
<https://gcc.gnu.org/wiki/CC0Transition> for a guide to converting GCC 
ports away from cc0.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[John Paul Adrian Glaubitz]

On 12/01/2017 11:40 PM, Joseph Myers wrote:
>> 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.

I will be happy to provide these test runs. I just came from OpenJDK were
I fixed many issues with non-stream architectures and I'm happy to pick
up glibc next and try to help fix issues.

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

J-Core is planning to eventually implement SH-4.

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

I have already contacted the guy who has started with ia64 again on
Debian and warned him about the deprecation issue.

>> 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 
> <https://gcc.gnu.org/ml/gcc/2017-07/msg00231.html> was that cc0 ports 
> could be deprecated for GCC 8 and removed for GCC 9 if not converted.  See 
> <https://gcc.gnu.org/wiki/CC0Transition> for a guide to converting GCC 
> ports away from cc0.

Yes, I'm aware of the LRA transition and this scares quite a lot. I don't
know whether I have the skillset to work on gcc, so far I have committed
merely one patch to gcc and that was only a small fix.

There is definitely demand for m68k support in gcc and glibc, the retro
community is huge, especially because of the Amiga which has been
refusing to die for 20 years. People have developed FPGA-based CPU
accelerators which boost the Amiga to 600 MHz and more and with qemu-m68k-system,
we can now emulate a Macintosh Quadra 800 machine with 1 GiB RAM and
a 1.5 GHz CPU which helps a lot when it comes to compiling and testing
code natively. I also have an actual Amiga running Debian unstable with
a 4.14 kernel and glibc_2.25/gcc-7. I will run the testsuite for
glibc-master on qemu-m68k-system for now.

SH has LRA support in gcc already, if I remember correctly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Adhemerval Zanella]

On 02/12/2017 13:14, John Paul Adrian Glaubitz wrote:
> On 12/01/2017 11:40 PM, Joseph Myers wrote:
>>> 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.
> 
> I will be happy to provide these test runs. I just came from OpenJDK were
> I fixed many issues with non-stream architectures and I'm happy to pick
> up glibc next and try to help fix issues.

There is some time I checked glibc status on m68k (and looks like I can't
access the machine now) and I can try to see if I can make/check glibc on
the machine (I am trying to recall why exactly prevented me to so on 2.26
release window).

> 
>>> 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).
> 
> J-Core is planning to eventually implement SH-4.
> 
>>> 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).
> 
> I have already contacted the guy who has started with ia64 again on
> Debian and warned him about the deprecation issue.

I would be nice if we could get access to real ia64 hardware (I tried to
use ski with mixed results).  ia64 thread stack allocation was broken
since 2.24 (d615a4735) and we just fixed it recently on master (01b87c656f)
and only though reports of Sergei Trofimovich (my ski environment did not
trigger the issue).

> 
>>> 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 
>> <https://gcc.gnu.org/ml/gcc/2017-07/msg00231.html> was that cc0 ports 
>> could be deprecated for GCC 8 and removed for GCC 9 if not converted.  See 
>> <https://gcc.gnu.org/wiki/CC0Transition> for a guide to converting GCC 
>> ports away from cc0.
> 
> Yes, I'm aware of the LRA transition and this scares quite a lot. I don't
> know whether I have the skillset to work on gcc, so far I have committed
> merely one patch to gcc and that was only a small fix.
> 
> There is definitely demand for m68k support in gcc and glibc, the retro
> community is huge, especially because of the Amiga which has been
> refusing to die for 20 years. People have developed FPGA-based CPU
> accelerators which boost the Amiga to 600 MHz and more and with qemu-m68k-system,
> we can now emulate a Macintosh Quadra 800 machine with 1 GiB RAM and
> a 1.5 GHz CPU which helps a lot when it comes to compiling and testing
> code natively. I also have an actual Amiga running Debian unstable with
> a 4.14 kernel and glibc_2.25/gcc-7. I will run the testsuite for
> glibc-master on qemu-m68k-system for now.
> 
> SH has LRA support in gcc already, if I remember correctly.

I see Linux/m68k being deprecated if and when we move to a minimum required
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).

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. 

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

[John Paul Adrian Glaubitz]

On 12/04/2017 12:10 PM, Adhemerval Zanella wrote:
>> I will be happy to provide these test runs. I just came from OpenJDK were
>> I fixed many issues with non-stream architectures and I'm happy to pick
>> up glibc next and try to help fix issues.
> 
> There is some time I checked glibc status on m68k (and looks like I can't
> access the machine now) and I can try to see if I can make/check glibc on
> the machine (I am trying to recall why exactly prevented me to so on 2.26
> release window).

This particular machine (an Aranym instance) is down at the moment. I do
have an Amiga 4000 here now up and running and I also did a testsuite
run on qemu-m68k-system which eventually bails out with:

gcc /srv/glibc/build/math/test-tgmath3.c -c -std=gnu11 -fgnu89-inline  -O2 -Wall -Werror -Wundef -Wwrite-strings -fmerge-all-constants -fno-stack-protector -frounding-math -g -Wstrict-prototypes -Wold-style-definition   -fno-builtin       -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/srv/glibc/build/math  -I/srv/glibc/build  -I../sysdeps/unix/sysv/linux/m68k/m680x0  -I../sysdeps/unix/sysv/linux/m68k  -I../sysdeps/m68k/nptl  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/m68k/m680x0/m68020  -I../sysdeps/m68k/m680x0/fpu  -I../sysdeps/m68k/m680x0  -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96  -I../sysdeps/m68k/fpu  -I../sysdeps/m68k  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT -include /srv/glibc/build/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o /srv/glibc/build/math/test-tgmath3.o -MD -MP -MF /srv/glibc/build/math/test-tgmath3.o.dt -MT /srv/glibc/build/math/test-tgmath3.o
virtual memory exhausted: Cannot allocate memory
../o-iterator.mk:9: recipe for target '/srv/glibc/build/math/test-tgmath3.o' failed
make[2]: *** [/srv/glibc/build/math/test-tgmath3.o] Error 1
make[2]: Leaving directory '/srv/glibc/math'
Makefile:215: recipe for target 'math/xtests' failed
make[1]: *** [math/xtests] Error 2
make[1]: Leaving directory '/srv/glibc'
Makefile:9: recipe for target 'xcheck' failed
make: *** [xcheck] Error 2

The source code file in question is 11 MiB large:

root@pacman:/srv/glibc/build# ls -lh /srv/glibc/build/math/test-tgmath3.c
-rw-r--r-- 1 root root 11M Dec  2 19:37 /srv/glibc/build/math/test-tgmath3.c
root@pacman:/srv/glibc/build#

>> I have already contacted the guy who has started with ia64 again on
>> Debian and warned him about the deprecation issue.
> 
> I would be nice if we could get access to real ia64 hardware (I tried to
> use ski with mixed results).  ia64 thread stack allocation was broken
> since 2.24 (d615a4735) and we just fixed it recently on master (01b87c656f)
> and only though reports of Sergei Trofimovich (my ski environment did not
> trigger the issue).

The guy working on ia64 in Debian is Jason Duerstock. He said, he will be
willing to provide a porterbox for ia64 soonish. I put him up in the CC
of this mail.

>> SH has LRA support in gcc already, if I remember correctly.
> 
> I see Linux/m68k being deprecated if and when we move to a minimum required
> 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).

I want to try my best to avoid this. There are many people currently hacking
on Linux/m68k and there has been a tremendous effort in the past 5-6 years
to resurrect the port. We are currently successfully building 10500 source
packages on Linux/m68k out of approximately 12000 packages which I don't
think is a too bad coverage.

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

FWIW, Debian is focusing on tilegx which is currently bootstrappable
with gcc-7, see: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7_supported/

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joseph Myers]

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

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

[Adhemerval Zanella]

On 04/12/2017 16:03, Joseph Myers wrote:
> 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).

I personally think it is too restrictive to remove the architecture in
such case if the minimum glibc required GCC version still provides support. 
I give you that it incur in a more troublesome testing because one will
need to pick an subset of supported compiler version, but in such case
we can set a policy of architecture being 'deprecated' and schedule for
future removal (maybe in a subsequent glibc release).

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

I think this sounds like a plan for 2.27. I will try to spend some cycles
on this in following weeks.

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

[Joseph Myers]

On Mon, 4 Dec 2017, Adhemerval Zanella wrote:

> I personally think it is too restrictive to remove the architecture in
> such case if the minimum glibc required GCC version still provides support. 

If the support for some architecture in GCC is no longer considered worth 
maintaining / updating (because, probably, the architecture itself is 
obsolescent), I think that is reasonable evidence that the support in 
glibc is also not worth maintaining / updating, even while it can in fact 
be built with older GCC versions.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Chris Metcalf]

On 12/4/2017 6:10 AM, Adhemerval Zanella wrote:
> 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.

That's certainly a plausible middle ground.   Of course, tilepro support is
only 30 files (about half of which are just *.abilist files) out of 204 
total
files for tile support, so the tree won't benefit as much from that cleanup.
But we have heard some support for tilegx, and none for tilepro, so maybe
that's a plausible position to land, particularly given the Debian interest.

For what it's worth, what I've heard from kernel maintainers suggests that
just marking tile as "Orphan" in the MAINTAINERS file and not deleting
any of the existing code is the right position in that community.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

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

[Adhemerval Zanella]

On 04/12/2017 16:13, Chris Metcalf wrote:
> On 12/4/2017 6:10 AM, Adhemerval Zanella wrote:
>> 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.
> 
> That's certainly a plausible middle ground.   Of course, tilepro support is
> only 30 files (about half of which are just *.abilist files) out of 204 total
> files for tile support, so the tree won't benefit as much from that cleanup.
> But we have heard some support for tilegx, and none for tilepro, so maybe
> that's a plausible position to land, particularly given the Debian interest.

We maintain a buildbot for all current supported architectures [1], which
means less computing resources being spent in build/checking in this
specific case.  As Joseph has put, tilepro removal will most likely incur
in some internal tile folder simplification.

[1] https://sourceware.org/ml/libc-testresults/

> 
> For what it's worth, what I've heard from kernel maintainers suggests that
> just marking tile as "Orphan" in the MAINTAINERS file and not deleting
> any of the existing code is the right position in that community.
> 

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

[Joseph Myers]

On Sat, 2 Dec 2017, John Paul Adrian Glaubitz wrote:

> On 12/01/2017 11:40 PM, Joseph Myers wrote:
> >> 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.
> 
> I will be happy to provide these test runs. I just came from OpenJDK were
> I fixed many issues with non-stream architectures and I'm happy to pick
> up glibc next and try to help fix issues.

Thanks.  Obviously testing and fixing test issues makes sense at any time, 
not just during the freeze - but it's during the freeze that we want 
results posted, with the hope that they'll be reasonably clean at release 
time (and then any remaining failures listed on the wiki page are a useful 
guide to what's expected for other people building and testing for that 
architecture).

> >> 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).
> 
> I have already contacted the guy who has started with ia64 again on
> Debian and warned him about the deprecation issue.

And we need to find out if Mike Frysinger wishes to continue as ia64 
maintainer or not.  Because if someone's listed as a maintainer but not in 
fact reviewing or committing patches, it may be harder to get patches in 
than if there's no maintainer, as other people will assume that the listed 
maintainer will do the review/commit and so generally not get involved 
with the architecture-specific patches (like that uncommitted 
libm-test-ulps patch).

> > 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 
> > <https://gcc.gnu.org/ml/gcc/2017-07/msg00231.html> was that cc0 ports 
> > could be deprecated for GCC 8 and removed for GCC 9 if not converted.  See 
> > <https://gcc.gnu.org/wiki/CC0Transition> for a guide to converting GCC 
> > ports away from cc0.
> 
> Yes, I'm aware of the LRA transition and this scares quite a lot. I don't
> know whether I have the skillset to work on gcc, so far I have committed
> merely one patch to gcc and that was only a small fix.

The away-from-cc0 transition is a lot more involved than the moving-to-LRA 
one, but only affects m68k (out of the glibc architectures).

There are several glibc architectures with no LRA support in their GCC 
ports at present, which may need such support added at some point in the 
next few years to avoid deprecation: alpha hppa ia64 m68k microblaze 
tilegx tilepro.

> a 4.14 kernel and glibc_2.25/gcc-7. I will run the testsuite for
> glibc-master on qemu-m68k-system for now.

Note there is at least one open bug for m68k glibc 
<https://sourceware.org/bugzilla/show_bug.cgi?id=13742> concerning use of 
fsincos instructions that are documented as inaccurate for large inputs.  
I would not be entirely confident that emulators accurately reflect the 
levels of accuracy or inaccuracy of such instructions in hardware.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[John Paul Adrian Glaubitz]

On 12/04/2017 06:53 PM, Joseph Myers wrote:
> Thanks.  Obviously testing and fixing test issues makes sense at any time, 
> not just during the freeze - but it's during the freeze that we want 
> results posted, with the hope that they'll be reasonably clean at release 
> time (and then any remaining failures listed on the wiki page are a useful 
> guide to what's expected for other people building and testing for that 
> architecture).

I agree. I will do my best to help with that. I already tested a gcc-7 patch
which implements __builtin_trap() on SH which is necessary to get glibc to
build on SH with gcc-7.

>> I have already contacted the guy who has started with ia64 again on
>> Debian and warned him about the deprecation issue.
> 
> And we need to find out if Mike Frysinger wishes to continue as ia64 
> maintainer or not.  Because if someone's listed as a maintainer but not in 
> fact reviewing or committing patches, it may be harder to get patches in 
> than if there's no maintainer, as other people will assume that the listed 
> maintainer will do the review/commit and so generally not get involved 
> with the architecture-specific patches (like that uncommitted 
> libm-test-ulps patch).

Good idea.

>> Yes, I'm aware of the LRA transition and this scares quite a lot. I don't
>> know whether I have the skillset to work on gcc, so far I have committed
>> merely one patch to gcc and that was only a small fix.
> 
> The away-from-cc0 transition is a lot more involved than the moving-to-LRA 
> one, but only affects m68k (out of the glibc architectures).
> 
> There are several glibc architectures with no LRA support in their GCC 
> ports at present, which may need such support added at some point in the 
> next few years to avoid deprecation: alpha hppa ia64 m68k microblaze 
> tilegx tilepro.

I think for hppa, there are John David Anglin and Helge Deller who are
very active. For alpha, there is Michael Cree who is Debian's alpha
maintainer. I don't know anyone for Microblaze.

For m68k, there is Andreas Schwab but I don't know whether he wants to
work on gcc itself. But there are many more people working on m68k,
it's a pity that none of them have worked on gcc.

>> a 4.14 kernel and glibc_2.25/gcc-7. I will run the testsuite for
>> glibc-master on qemu-m68k-system for now.
> 
> Note there is at least one open bug for m68k glibc 
> <https://sourceware.org/bugzilla/show_bug.cgi?id=13742> concerning use of 
> fsincos instructions that are documented as inaccurate for large inputs.  
> I would not be entirely confident that emulators accurately reflect the 
> levels of accuracy or inaccuracy of such instructions in hardware.

I have real hardware running, so I can help with this issue. Thanks
for pointing me at the issue.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joseph Myers]

On Mon, 4 Dec 2017, John Paul Adrian Glaubitz wrote:

> > Note there is at least one open bug for m68k glibc 
> > <https://sourceware.org/bugzilla/show_bug.cgi?id=13742> concerning use of 
> > fsincos instructions that are documented as inaccurate for large inputs.  
> > I would not be entirely confident that emulators accurately reflect the 
> > levels of accuracy or inaccuracy of such instructions in hardware.
> 
> I have real hardware running, so I can help with this issue. Thanks
> for pointing me at the issue.

If there is a real problem here then the simplest fix may simply be 
avoiding m68k-specific implementations of these functions and using the 
generic ones instead (as was done on x86 / x86_64 some years ago).

(libm-test-ulps for m68k hasn't been updated since 2015.  You'd need to 
update it before the libm testsuite can usefully identify other problems 
that may be present.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Adhemerval Zanella]

On 31/01/2018 16:15, John Paul Adrian Glaubitz wrote:
> On 01/31/2018 06:37 PM, Joseph Myers wrote:
>> The 2.27 release is due out tomorrow.  So far, no test results for tile 
>> have been posted at <https://sourceware.org/glibc/wiki/Release/2.27> - and 
>> the same applies to sh and ia64, which also had some interest in them 
>> expressed in this thread.  Are you, or other people you're working with 
>> who have interest in those architectures, working on having results for 
>> those architectures for 2.27 for the wiki page (regenerating libm test 
>> ulps first and getting that regeneration checked in if there would 
>> otherwise be tests failing only because of lack of updated ulps)?
> 
> I don't have access to tile hardware at the moment, but sh4 and ia64.
> 
> Adhemerval has access to the sparc64, sh4 and ia64 boxes as well and
> he said he would be working on the ia64 stuff.
> 
> If he doesn't run the testsuite on these architectures, I can do that
> later next week.
> 
> Adrian
> 

Hi Adrian,

Trying to build/run glibc testsuite against sh4 own toolchain I am facing
an build issue for some tests:

---
gcc -nostdlib -nostartfiles -o /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++    -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/azanella/glibc/glibc-git-build/csu/crt1.o /home/azanella/glibc/glibc-git-build/csu/crti.o `gcc  --print-file-name=crtbegin.o` /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++.o /home/azanella/glibc/glibc-git-build/support/libsupport_nonshared.a -lstdc++ -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-rpath-link=/home/azanella/glibc/glibc-git-build:/home/azanella/glibc/glibc-git-build/math:/home/azanella/glibc/glibc-git-build/elf:/home/azanella/glibc/glibc-git-build/dlfcn:/home/azanella/glibc/glibc-git-build/nss:/home/azanella/glibc/glibc-git-build/nis:/home/azanella/glibc/glibc-git-build/rt:/home/azanella/glibc/glibc-git-build/resolv:/home/azanella/glibc/glibc-git-build/crypt:/home/azanella/glibc/glibc-git-build/mathvec:/home/azanella/glibc/glibc-git-build/support:/home/azanella/glibc/glibc-git-build/nptl /home/azanella/glibc/glibc-git-build/libc.so.6 /home/azanella/glibc/glibc-git-build/libc_nonshared.a -Wl,--as-needed /home/azanella/glibc/glibc-git-build/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o` /home/azanella/glibc/glibc-git-build/csu/crtn.o
/usr/lib/gcc/sh4-linux-gnu/7/libgcc_s.so.1: undefined reference to `__fpscr_values@GLIBC_2.2'
collect2: error: ld returned 1 exit status
---

I did not dig into this, but some google shows it has been an issue before [1].
The issue is using build-many-glibcs.py cross toolchain I did not see any
issues building glibc testsuite.

The major gcc configuration differences I see is system one adds a 
'--with-cpu=sh4 --with-multilib-list=m4,m4-nofpu'. Any idea of what might
be happening.

[1] https://sourceware.org/ml/libc-alpha/2009-01/msg00034.html

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

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 2071 bytes --]

On Thu, 1 Feb 2018, Adhemerval Zanella wrote:

> Trying to build/run glibc testsuite against sh4 own toolchain I am facing
> an build issue for some tests:
> 
> ---
> gcc -nostdlib -nostartfiles -o /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++    -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/azanella/glibc/glibc-git-build/csu/crt1.o /home/azanella/glibc/glibc-git-build/csu/crti.o `gcc  --print-file-name=crtbegin.o` /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++.o /home/azanella/glibc/glibc-git-build/support/libsupport_nonshared.a -lstdc++ -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-rpath-link=/home/azanella/glibc/glibc-git-build:/home/azanella/glibc/glibc-git-build/math:/home/azanella/glibc/glibc-git-build/elf:/home/azanella/glibc/glibc-git-build/dlfcn:/home/azanella/glibc/glibc-git-build/nss:/home/azanella/glibc/glibc-git-build/nis:/home/azanella/glibc/glibc-git-build/rt:/home/azanella/glibc/glibc-git-build/resolv:/home/azanella/glibc/glibc-git-build/crypt:/home/azanella/glibc/glibc-git-build/mathvec:/home/azanella/glibc/glibc-git-build/support:/home/azanella/glibc/glibc-git-build/nptl /home/azanella/glibc/glibc-git-build/libc.so.6 /home/azanella/glibc/glibc-git-build/libc_nonshared.a -Wl,--as-needed /home/azanella/glibc/glibc-git-build/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o` /home/azanella/glibc/glibc-git-build/csu/crtn.o
> /usr/lib/gcc/sh4-linux-gnu/7/libgcc_s.so.1: undefined reference to `__fpscr_values@GLIBC_2.2'
> collect2: error: ld returned 1 exit status

I think some distributions have a local glibc patch related to 
__fpscr_values, so a newly built glibc may be ABI-incompatible with 
binaries built against such a patched glibc.  (The use of __fpscr_values 
is fundamentally flawed, but that was supposed to be fixed for GCC 5 - see 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513> and its duplicate 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60138>.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Adhemerval Zanella]

On 01/02/2018 11:49, Joseph Myers wrote:
> On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> 
>> Trying to build/run glibc testsuite against sh4 own toolchain I am facing
>> an build issue for some tests:
>>
>> ---
>> gcc -nostdlib -nostartfiles -o /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++    -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both /home/azanella/glibc/glibc-git-build/csu/crt1.o /home/azanella/glibc/glibc-git-build/csu/crti.o `gcc  --print-file-name=crtbegin.o` /home/azanella/glibc/glibc-git-build/assert/tst-assert-c++.o /home/azanella/glibc/glibc-git-build/support/libsupport_nonshared.a -lstdc++ -Wl,-dynamic-linker=/lib/ld-linux.so.2 -Wl,-rpath-link=/home/azanella/glibc/glibc-git-build:/home/azanella/glibc/glibc-git-build/math:/home/azanella/glibc/glibc-git-build/elf:/home/azanella/glibc/glibc-git-build/dlfcn:/home/azanella/glibc/glibc-git-build/nss:/home/azanella/glibc/glibc-git-build/nis:/home/azanella/glibc/glibc-git-build/rt:/home/azanella/glibc/glibc-git-build/resolv:/home/azanella/glibc/glibc-git-build/crypt:/home/azanella/glibc/glibc-git-build/mathvec:/home/azanella/glibc/glibc-git-build/support:/home/azanella/glibc/glibc-git-build/nptl /home/azanella/glibc/glibc-git-build/libc.so.6 /home/azanella/glibc/glibc-git-build/libc_nonshared.a -Wl,--as-needed /home/azanella/glibc/glibc-git-build/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o` /home/azanella/glibc/glibc-git-build/csu/crtn.o
>> /usr/lib/gcc/sh4-linux-gnu/7/libgcc_s.so.1: undefined reference to `__fpscr_values@GLIBC_2.2'
>> collect2: error: ld returned 1 exit status
> 
> I think some distributions have a local glibc patch related to 
> __fpscr_values, so a newly built glibc may be ABI-incompatible with 
> binaries built against such a patched glibc.  (The use of __fpscr_values 
> is fundamentally flawed, but that was supposed to be fixed for GCC 5 - see 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53513> and its duplicate 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60138>.)
> 

I do think it is the case, checking the debian package addendum from libc6-dev [1]
I noted it indeed adds this patch:

$ cat local-fpcscr_values.diff
--- a/sysdeps/unix/sysv/linux/sh/sysdep.S
+++ b/sysdeps/unix/sysv/linux/sh/sysdep.S
@@ -30,3 +30,14 @@

 #define __syscall_error __syscall_error_1
 #include <sysdeps/unix/sh/sysdep.S>
+
+       .data
+       .align 3
+       .globl ___fpscr_values
+       .type ___fpscr_values, @object
+       .size ___fpscr_values, 8
+___fpscr_values:
+       .long 0
+       .long 0x80000
+weak_alias (___fpscr_values, __fpscr_values)
+
--- a/sysdeps/unix/sysv/linux/sh/Versions
+++ b/sysdeps/unix/sysv/linux/sh/Versions
@@ -2,6 +2,7 @@
   GLIBC_2.2 {
     # functions used in other libraries
     __xstat64; __fxstat64; __lxstat64;
+    __fpscr_values;
 
     # a*
     alphasort64;
--- a/sysdeps/unix/sysv/linux/sh/libc.abilist
+++ b/sysdeps/unix/sysv/linux/sh/libc.abilist
@@ -267,6 +267,7 @@
 GLIBC_2.2 __flbf F
 GLIBC_2.2 __fork F
 GLIBC_2.2 __fpending F
+GLIBC_2.2 __fpscr_values D 0x8
 GLIBC_2.2 __fpu_control D 0x4
 GLIBC_2.2 __fpurge F
 GLIBC_2.2 __freadable F

I will check glibc with patch applied and try to rebuild a canadian cross to check
against a baseline toolchain.

[1] https://packages.debian.org/it/sid/libc6-dev

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

[Adhemerval Zanella]

On 31/01/2018 17:29, Adhemerval Zanella wrote:
> 
> 
> On 31/01/2018 16:15, John Paul Adrian Glaubitz wrote:
>> On 01/31/2018 06:37 PM, Joseph Myers wrote:
>>> The 2.27 release is due out tomorrow.  So far, no test results for tile 
>>> have been posted at <https://sourceware.org/glibc/wiki/Release/2.27> - and 
>>> the same applies to sh and ia64, which also had some interest in them 
>>> expressed in this thread.  Are you, or other people you're working with 
>>> who have interest in those architectures, working on having results for 
>>> those architectures for 2.27 for the wiki page (regenerating libm test 
>>> ulps first and getting that regeneration checked in if there would 
>>> otherwise be tests failing only because of lack of updated ulps)?
>>
>> I don't have access to tile hardware at the moment, but sh4 and ia64.
>>
>> Adhemerval has access to the sparc64, sh4 and ia64 boxes as well and
>> he said he would be working on the ia64 stuff.
> 
> I will work on ia64 and sh4 results this week.
> 

ia64 seems to be in a good shape with only two issues which requires further
investigation (nptl/tst-cancel21-static and stdlib/tst-makecontext3 and
for the later I think it is a long-standing issue).

However the math tests seems to shows a lot of corner cases issues which
has been fixed in generic implementations. As I commented with Jason Duerstock,
John Paul Adrian, and James Clarke in a private thread I think easier solution
for 2.28 is we remove the arch-specific faulty ia64 math implementation and
use the generic ones. If performance is an issue we reimplement and fixed
them if it is the case.

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

[John Paul Adrian Glaubitz]

On 02/01/2018 02:24 PM, Adhemerval Zanella wrote:
> ia64 seems to be in a good shape with only two issues which requires further
> investigation (nptl/tst-cancel21-static and stdlib/tst-makecontext3 and
> for the later I think it is a long-standing issue).

Sounds good :). Then I think I am mostly worried with sparc64. It has
really lots of testsuite failures.

> However the math tests seems to shows a lot of corner cases issues which
> has been fixed in generic implementations. As I commented with Jason Duerstock,
> John Paul Adrian, and James Clarke in a private thread I think easier solution

You can just say Adrian :-).

> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
> use the generic ones. If performance is an issue we reimplement and fixed
> them if it is the case.

Do you think you could whip up a patch that we can apply to the 2.26 package
in Debian? If it's just a matter of disabling ia64-specific code, it shouldn't
be too difficult, should it?

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Adhemerval Zanella]

On 01/02/2018 11:33, John Paul Adrian Glaubitz wrote:
> On 02/01/2018 02:24 PM, Adhemerval Zanella wrote:
>> ia64 seems to be in a good shape with only two issues which requires further
>> investigation (nptl/tst-cancel21-static and stdlib/tst-makecontext3 and
>> for the later I think it is a long-standing issue).
> 
> Sounds good :). Then I think I am mostly worried with sparc64. It has
> really lots of testsuite failures.

I will check sparcv9/sparc64 later today as well.

> 
>> However the math tests seems to shows a lot of corner cases issues which
>> has been fixed in generic implementations. As I commented with Jason Duerstock,
>> John Paul Adrian, and James Clarke in a private thread I think easier solution
> 
> You can just say Adrian :-).
> 
>> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
>> use the generic ones. If performance is an issue we reimplement and fixed
>> them if it is the case.
> 
> Do you think you could whip up a patch that we can apply to the 2.26 package
> in Debian? If it's just a matter of disabling ia64-specific code, it shouldn't
> be too difficult, should it?

If it is a matter of code removal I think backport should not be difficult.

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

[Joseph Myers]

On Thu, 1 Feb 2018, Adhemerval Zanella wrote:

> On 01/02/2018 11:33, John Paul Adrian Glaubitz wrote:
> > On 02/01/2018 02:24 PM, Adhemerval Zanella wrote:
> >> ia64 seems to be in a good shape with only two issues which requires further
> >> investigation (nptl/tst-cancel21-static and stdlib/tst-makecontext3 and
> >> for the later I think it is a long-standing issue).
> > 
> > Sounds good :). Then I think I am mostly worried with sparc64. It has
> > really lots of testsuite failures.
> 
> I will check sparcv9/sparc64 later today as well.

Note that for 32-bit SPARC you should make sure to use -mlong-double-128 
with the compiler (for some reason the 32-bit multilib of a sparc64 
compiler doesn't default to that, even when GCC is configured against a 
current glibc version - see 
<https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html>).  At least, I 
suspect this peculiarity explains the linknamespace failures listed at 
<https://sourceware.org/glibc/wiki/Release/2.26#SPARC_.2832-bit.29> - 
which represent a genuine namespace bug in the nldbl-compat code, but not 
one that should show up in normal testing.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Adhemerval Zanella]

On 01/02/2018 11:45, Joseph Myers wrote:
> On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> 
>> On 01/02/2018 11:33, John Paul Adrian Glaubitz wrote:
>>> On 02/01/2018 02:24 PM, Adhemerval Zanella wrote:
>>>> ia64 seems to be in a good shape with only two issues which requires further
>>>> investigation (nptl/tst-cancel21-static and stdlib/tst-makecontext3 and
>>>> for the later I think it is a long-standing issue).
>>>
>>> Sounds good :). Then I think I am mostly worried with sparc64. It has
>>> really lots of testsuite failures.
>>
>> I will check sparcv9/sparc64 later today as well.
> 
> Note that for 32-bit SPARC you should make sure to use -mlong-double-128 
> with the compiler (for some reason the 32-bit multilib of a sparc64 
> compiler doesn't default to that, even when GCC is configured against a 
> current glibc version - see 
> <https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html>).  At least, I 
> suspect this peculiarity explains the linknamespace failures listed at 
> <https://sourceware.org/glibc/wiki/Release/2.26#SPARC_.2832-bit.29> - 
> which represent a genuine namespace bug in the nldbl-compat code, but not 
> one that should show up in normal testing.
> 

Right, I will rerun the tests with -mlong-double-128 explicit set.

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

[Joseph Myers]

On Thu, 1 Feb 2018, Adhemerval Zanella wrote:

> However the math tests seems to shows a lot of corner cases issues which
> has been fixed in generic implementations. As I commented with Jason Duerstock,
> John Paul Adrian, and James Clarke in a private thread I think easier solution
> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
> use the generic ones. If performance is an issue we reimplement and fixed
> them if it is the case.

(a) Note that various functions don't have a generic ldbl-96 
implementation, because all of x86_64, i386, ia64 and m68k have 
architecture-specific implementations.  So in those cases you can't simply 
remove the ia64 implementation because there isn't an alternative one.

(b) Where the issue is just errno setting, that code is often in C rather 
than ia64 assembly and so the existing implementation is probably easy to 
fix - indeed, there is a patch (from 2009) attached to bug 10163 to fix 
some such cases (including some where .S files are involved).  I've not 
checked whether that patch works, whether it applies to current sources, 
whether any of the issues there are already fixed or whether it's correct, 
but it's at least plausible for fixing some such bugs if it does indeed 
eliminate failures for the affected functions without introducing 
regressions.

(c) Of course, any fix, whether by removing an ia64-specific 
implementation or by fixing it, should have a bug filed in Bugzilla first 
stating what the actual bug is (we already have three such bugs).

(d) If you remove ia64-specific implementations you need to be careful not 
to introduce __*_finite symbols at old symbol versions (the ia64 
implementation doesn't have such symbols - it's probably not useful to add 
them piecemeal without having an ia64 bits/math-finite.h that would use 
them, but if added they should of course be at a new symbol version, not 
the version where they were originally added for other architectures).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Adhemerval Zanella]

On 01/02/2018 11:39, Joseph Myers wrote:
> On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> 
>> However the math tests seems to shows a lot of corner cases issues which
>> has been fixed in generic implementations. As I commented with Jason Duerstock,
>> John Paul Adrian, and James Clarke in a private thread I think easier solution
>> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
>> use the generic ones. If performance is an issue we reimplement and fixed
>> them if it is the case.
> 
> (a) Note that various functions don't have a generic ldbl-96 
> implementation, because all of x86_64, i386, ia64 and m68k have 
> architecture-specific implementations.  So in those cases you can't simply 
> remove the ia64 implementation because there isn't an alternative one.

My idea is to focus first on flt-32 and dbl-64 ones to check how many
failures we can remove by using generic implementations.

> 
> (b) Where the issue is just errno setting, that code is often in C rather 
> than ia64 assembly and so the existing implementation is probably easy to 
> fix - indeed, there is a patch (from 2009) attached to bug 10163 to fix 
> some such cases (including some where .S files are involved).  I've not 
> checked whether that patch works, whether it applies to current sources, 
> whether any of the issues there are already fixed or whether it's correct, 
> but it's at least plausible for fixing some such bugs if it does indeed 
> eliminate failures for the affected functions without introducing 
> regressions.

Mostly of the issues indeed seems to be just errno related and BZ#10163 fix
should help these out. However some are issue with non-default rounding mode,
sNAN/qNAN, and exceptions handling. For test-double tests, for a quick
overview I see:

math/test-double-atan2
math/test-double-atanh
math/test-double-cos
math/test-double-erfc
math/test-double-fdim
math/test-double-fmod
math/test-double-remainder
math/test-double-sin
math/test-double-sincos
math/test-double-tan
- Wrong errno

math/test-double-ceil
math/test-double-finite-ceil
math/test-double-finite-floor
math/test-double-floor
- Setting inexact

math/test-double-cosh
math/test-double-exp
math/test-double-exp10
math/test-double-exp2
- Return INF for non default rounding values

math/test-double-fabs
- sNAN and invalid exception

math/test-double-pow
math/test-double-finite-pow

testing double (finite-math-only)
Failure: Test: pow (-0x2.00004p+0, -0x3.fep+8)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:   2.2207407279229960e-308   0x0.ff805fe2b3544p-1022
 difference:  2.2207407279229960e-308   0x0.ff805fe2b3544p-1022
 ulp       :  4494829273429316.0000
 max.ulp   :  0.0000
Failure: Test: pow (-0x2.00004p+0, -0x3.fffp+12)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  -0.0000000000000000e+00  -0x0.0000000000000p+0
 difference:  0.0000000000000000e+00   0x0.0000000000000p+0
 ulp       :  0.0000
 max.ulp   :  0.0000
Failure: Test: pow (-0x2.00008p+0, -0x3.fep+8)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:   2.2164160439602859e-308   0x0.ff00ff758ff33p-1022
 difference:  2.2164160439602859e-308   0x0.ff00ff758ff33p-1022
 ulp       :  4486076015640371.0000
 max.ulp   :  0.0000
Failure: Test: pow (-0x2.00008p+0, -0x3.fffp+12)
Result:
 is:          0.0000000000000000e+00   0x0.0000000000000p+0
 should be:  -0.0000000000000000e+00  -0x0.0000000000000p+0
 difference:  0.0000000000000000e+00   0x0.0000000000000p+0
 ulp       :  0.0000

math/test-double-scalb
math/test-double-finite-scalb
math/test-double-lgamma
math/test-double-tgamma
- Wrong errno and some non-default rounding issues:

Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: Test: scalb_downward (1, max_value)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: Test: scalb_downward (min_value, max_value)

Failure: Test: lgamma_downward (0x5.d53649e2d46c8p+1012)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: Test: lgamma_downward (0xf.ffffffffffff8p+1020)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023

Failure: Test: tgamma (-0x1p-1024)
Result:
 is:          inf   inf
 should be:  -inf  -inf

math/test-double-fmax
math/test-double-frexp
math/test-double-hypot
- sNaN not resulting in qNaN

math/test-double-sinh
- some non-default rounding issues:

testing double (without inline functions)
Failure: Test: sinh_downward (0x2.c5d374p+12)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: Test: sinh_downward (0x2.c5d37700c6bb2p+12)
Result:
 is:          inf   inf
 should be:   1.7976931348623157e+308   0x1.fffffffffffffp+1023
Failure: Test: sinh_downward (0x2.c5d37700c6bbp+12)


Based on results for some tests I still think using generic implementation
for some symbols seems a better strategy (for ceil, floor, and fabs at
least).

> 
> (c) Of course, any fix, whether by removing an ia64-specific 
> implementation or by fixing it, should have a bug filed in Bugzilla first 
> stating what the actual bug is (we already have three such bugs).

Right, I will open bug for current issues.

> 
> (d) If you remove ia64-specific implementations you need to be careful not 
> to introduce __*_finite symbols at old symbol versions (the ia64 
> implementation doesn't have such symbols - it's probably not useful to add 
> them piecemeal without having an ia64 bits/math-finite.h that would use 
> them, but if added they should of course be at a new symbol version, not 
> the version where they were originally added for other architectures).
> 

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

[Joseph Myers]

On Thu, 1 Feb 2018, Adhemerval Zanella wrote:

> On 01/02/2018 11:39, Joseph Myers wrote:
> > On Thu, 1 Feb 2018, Adhemerval Zanella wrote:
> > 
> >> However the math tests seems to shows a lot of corner cases issues which
> >> has been fixed in generic implementations. As I commented with Jason Duerstock,
> >> John Paul Adrian, and James Clarke in a private thread I think easier solution
> >> for 2.28 is we remove the arch-specific faulty ia64 math implementation and
> >> use the generic ones. If performance is an issue we reimplement and fixed
> >> them if it is the case.
> > 
> > (a) Note that various functions don't have a generic ldbl-96 
> > implementation, because all of x86_64, i386, ia64 and m68k have 
> > architecture-specific implementations.  So in those cases you can't simply 
> > remove the ia64 implementation because there isn't an alternative one.
> 
> My idea is to focus first on flt-32 and dbl-64 ones to check how many
> failures we can remove by using generic implementations.

How helpful that is may depend, in cases where there's no generic ldbl-96 
version, on whether the bugs and implementations are essentially the same 
as in the long double functions (if essentially the same and there's no 
generic ldbl-96 version of that function, fixing the ia64 long double 
version may give you a fix that's very similar to what's needed for float 
and double).

> math/test-double-ceil
> math/test-double-finite-ceil
> math/test-double-finite-floor
> math/test-double-floor
> - Setting inexact

I should point out that ia64 has four fpsr status fields, and that 
floating-point instructions can choose which status field to use.  
Furthermore, the ABI specifies "Status Fields 2 and 3. The control bits in 
these status fields must agree with the control bits in status field 0, 
and the trap disable bits should always be set at procedure calls and 
returns. The flag bits are always available for scratch use.".

I.e., for these functions setting spurious exceptions, you should just be 
able to change whatever instructions might set exceptions to set those 
exceptions in sf2 or sf3 instead.  (Or if round-to-nearest is wanted 
internally, sf1 can be used, as its flag bits are also scratch - many of 
the functions do already use sf1 on most of their computations.)

On the other hand, if the functions are explicitly setting inexact - which 
in fact appears to be the case for these functions - then the code that is 
only there to set inexact can be removed.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

On Thu, 1 Feb 2018, Adhemerval Zanella wrote:

> math/test-double-cosh
> math/test-double-exp
> math/test-double-exp10
> math/test-double-exp2
> - Return INF for non default rounding values

I should also note that it's probably possible to fix up the return values 
(by recomputing an overflowing expression in the original rounding mode) 
in the C error handling code in libm_error.c (only the _POSIX_ case is now 
reachable for newly linked programs).  That applies to all of float / 
double / long double.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

On Wed, 31 Jan 2018, Adhemerval Zanella wrote:

> I will work on ia64 and sh4 results this week.

Looking at the sh4 results you posted on the wiki, I see you note many NaN 
issues.

It seems from sh manuals that sh in fact uses the same reversed quiet / 
signaling NaN convention as hppa and older mips (I haven't checked if 
J-Core keeps this peculiarity - if it doesn't, that's a new ABI).  So to 
fix those failures, you need:

* Fix GCC to use mips_single_format / mips_double_format on sh (and 
preferably backport this to active release branches so those generate the 
correct NaNs there).

* Fix (with bug filed first, as a user-visible issue) glibc to know the 
NaN format for sh as well (nan-high-order-bit.h needed, and 
sysdeps/sh/soft-fp/sfp-machine.h should have _FP_QNANNEGATEDP and 
_FP_NANFRAC_* updated as in the non-NAN2008 case of 
sysdeps/mips/mips32/sfp-machine.h).

Given those fixed, you might then get more meaningful test results for 
sh4.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Chris Metcalf]

On 12/1/2017 4:57 PM, John Paul Adrian Glaubitz wrote:
>> 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.

OK, I'm testing the fix for that issue, and I will push it up if it passes.

I'd be very happy if someone from Debian (for example) wants to sign
up as maintainer.  Otherwise I will follow the sense of the community
in terms of whether deletion or just marking it as unmaintained feels
like the better way to go.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

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

[John Paul Adrian Glaubitz]

On 12/02/2017 02:14 AM, Chris Metcalf wrote:
> OK, I'm testing the fix for that issue, and I will push it up if it passes.

Thanks. This is highly appreciated!

> I'd be very happy if someone from Debian (for example) wants to sign
> up as maintainer.  Otherwise I will follow the sense of the community
> in terms of whether deletion or just marking it as unmaintained feels
> like the better way to go.

I will ask around the Debian community what the current state of the
Tilegx bootstrap is. Again, thanks for your help!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Chris Metcalf]

On 12/2/2017 10:16 AM, John Paul Adrian Glaubitz wrote:
> On 12/02/2017 02:14 AM, Chris Metcalf wrote:
>> OK, I'm testing the fix for that issue, and I will push it up if it passes.
> Thanks. This is highly appreciated!

Just posted it (and a trival ULPs update).   There are some other new 
failures
relative to 2.25, but they go away if I run with TIMEOUTFACTOR=10,
so I'm going to pretend they don't exist:

FAIL: malloc/tst-malloc-tcache-leak
FAIL: malloc/tst-malloc_info
FAIL: posix/tst-glob-tilde
FAIL: posix/tst-glob-tilde-mem
FAIL: resolv/mtrace-tst-resolv-res_ninit
FAIL: resolv/tst-resolv-res_ninit

The one other new failure is due to the compat-only, never-upstreamed
"set_dataplane" syscall, and I'm not sure if there's an obvious fix for 
that:

FAIL: misc/tst-syscall-list

I will commit the string change in a day or two if no one has any issues
with it; I already pushed the update to ULPs.

>> I'd be very happy if someone from Debian (for example) wants to sign
>> up as maintainer.  Otherwise I will follow the sense of the community
>> in terms of whether deletion or just marking it as unmaintained feels
>> like the better way to go.
> I will ask around the Debian community what the current state of the
> Tilegx bootstrap is. Again, thanks for your help!

Sounds good.  If someone from the Debian community wants to step up as
maintainer, that would be great.  Otherwise, based on what I've heard so 
far,
it sounds like we will plan to delete tilepro support, but somehow mark
tilegx as unmaintained and leave it in the tree.  I think Adhermerval is
willing to handle moving things around in the tree, etc., to make tilegx the
only tile architecture - thanks for volunteering!

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

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

[Joseph Myers]

On Mon, 4 Dec 2017, Chris Metcalf wrote:

> The one other new failure is due to the compat-only, never-upstreamed
> "set_dataplane" syscall, and I'm not sure if there's an obvious fix for that:
> 
> FAIL: misc/tst-syscall-list

If you have a local patch to the kernel headers adding a syscall there, 
you do indeed need a local syscall-names.list patch as well.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Arnd Bergmann]

On Sat, Dec 2, 2017 at 4:16 PM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On 12/02/2017 02:14 AM, Chris Metcalf wrote:
>
>> I'd be very happy if someone from Debian (for example) wants to sign
>> up as maintainer.  Otherwise I will follow the sense of the community
>> in terms of whether deletion or just marking it as unmaintained feels
>> like the better way to go.
>
> I will ask around the Debian community what the current state of the
> Tilegx bootstrap is. Again, thanks for your help!

Do you have any updates on this? A related question has come up
for the kernel, as are in the process of removing a number of architectures,
https://lwn.net/SubscriberLink/748074/119aaf0d62b3e6c1/ or
see https://lwn.net/Articles/748074/ for a nice summary.

It looks like we might remove blackfin and/or mn10300 at the same
time as the others, which would leave tile as the one architecture
whose future still remains unclear.

This is what I understand from previous discussions:

- Mellanox has stopped all work on the architecture, both kernel
  and glibc
- Cisco are using a heavily patched older kernel and mainline
  toolchains, they would not care about the kernel dropping
  the port (based on Henrik's mail in this thread)
- Mikrotik are probably using a similar kernel (I found a large
  3.3.5 based patch for tile in their latest download sources),
  so I'm guessing they wouldn't care either.
- There was a minor effort back in 2014 to try to get OpenWRT
  to run on mikrotik tile-gx based devices, but that doesn't seem
  to have gone anywhere
  (see https://forum.mikrotik.com/viewtopic.php?t=85713,
   https://forum.openwrt.org/viewtopic.php?id=50897)
- Helmut Grohne has done the work to add tile-gx to debian
   rebootstrap, and send several patches, as seen in
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
   However, I could find no information on this actually
   being turned into a full port, or anyone still actively involved
   in it. The Debian rebootstrap page at
   https://wiki.debian.org/HelmutGrohne/rebootstrap
   mentions lots of other architectures, but not this one.

Does anyone have any additional information here? If there
is still active work on OpenWRT or Debian for TileGX, I don't
want to hurt that, but if the port is indeed as dead as it seems
based on my findings above, then it would be convenient to
remove it from the kernel together with the other architectures
rather than waiting a few more releases.

      Arnd

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

[Joseph Myers]

On Wed, 7 Mar 2018, Arnd Bergmann wrote:

> Do you have any updates on this? A related question has come up
> for the kernel, as are in the process of removing a number of architectures,
> https://lwn.net/SubscriberLink/748074/119aaf0d62b3e6c1/ or
> see https://lwn.net/Articles/748074/ for a nice summary.

No-one has posted glibc test results for 2.27 or 2.26, despite the prior 
claims of interest in keeping the glibc port.  If the kernel port is 
removed, my assumption is that we should remove the glibc port at that 
point (not keep it around for possible use with older kernels).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[John Paul Adrian Glaubitz]

On 03/07/2018 05:00 PM, Joseph Myers wrote:
> No-one has posted glibc test results for 2.27 or 2.26, despite the prior
> claims of interest in keeping the glibc port.

To be honest, I find the rapid release model for glibc a bit annoying
as a downstream. Upstream projects which adopt this model and then require
constant attention from porters cause lots of stress for the less common
architectures. There are other upstream projects that want attention as
well and at some point it just will get extremely frustrating.

Is such a rapid release model really needed for something like a C library?

As for the testsuites: Adhemerval has gotten access from Debian to a
number of porterboxes for the various uncommon architectures, including
alpha, hppa, powerpcspe, sh4 and sparc64 and we're happy to give out
accounts to anyone interested.

And since Debian regularly updates glibc as well, you can get most testsuite
runs also by just checking the build logs (click on the green or red texts):

> https://buildd.debian.org/status/package.php?p=glibc&suite=sid

Note: Testsuites for sh4 and m68k are currently disabled.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Adhemerval Zanella]

On 07/03/2018 13:08, John Paul Adrian Glaubitz wrote:
> On 03/07/2018 05:00 PM, Joseph Myers wrote:
>> No-one has posted glibc test results for 2.27 or 2.26, despite the prior
>> claims of interest in keeping the glibc port.
> 
> To be honest, I find the rapid release model for glibc a bit annoying
> as a downstream. Upstream projects which adopt this model and then require
> constant attention from porters cause lots of stress for the less common
> architectures. There are other upstream projects that want attention as
> well and at some point it just will get extremely frustrating.
> 
> Is such a rapid release model really needed for something like a C library?

My understanding it is aligns with fedora release cycle. We have the advantage
of early testing based on distro userbase, but I also don't have a strong
opinion to have a per year release.

> 
> As for the testsuites: Adhemerval has gotten access from Debian to a
> number of porterboxes for the various uncommon architectures, including
> alpha, hppa, powerpcspe, sh4 and sparc64 and we're happy to give out
> accounts to anyone interested.

Btw I have added 2.26 and 2.27 tests results for alpha, hppa, sh4, sparc64,
and sparcv9.  The powerpspe I thought we should be covered since we had
powerpc hard float and soft float, but with recent build issues I think I
will add it on the loop.

> 
> And since Debian regularly updates glibc as well, you can get most testsuite
> runs also by just checking the build logs (click on the green or red texts):
> 
>> https://buildd.debian.org/status/package.php?p=glibc&suite=sid
> 
> Note: Testsuites for sh4 and m68k are currently disabled.
> 
> Adrian
> 

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

[Joseph Myers]

On Wed, 7 Mar 2018, Adhemerval Zanella wrote:

> and sparcv9.  The powerpspe I thought we should be covered since we had
> powerpc hard float and soft float, but with recent build issues I think I
> will add it on the loop.

I expect some extra math/ test failures for powerpcspe as well.  There's a 
documented processor erratum for wrong signs of zero results for 
single-precision floating-point results (erratum CPU 4 at 
<https://www.nxp.com/docs/en/errata/MPC8548ECE.pdf>), which resulted in 
test failures the last time I tried, and an undocumented (as far as I 
know) issue with not implementing proper before-rounding tininess 
detection.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Helmut Grohne]

On Wed, Mar 07, 2018 at 04:39:47PM +0100, Arnd Bergmann wrote:
> - Helmut Grohne has done the work to add tile-gx to debian
>    rebootstrap, and send several patches, as seen in
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
>    However, I could find no information on this actually
>    being turned into a full port, or anyone still actively involved
>    in it. The Debian rebootstrap page at
>    https://wiki.debian.org/HelmutGrohne/rebootstrap
>    mentions lots of other architectures, but not this one.

I happened help tilegx, because Adrian found someone with hw and tilegx
appeared to be very well maintained upstream. Very little needed to be
done to make it work in Debian. The patches I sent were pretty generic
and addressed issues that most ports face. What is there allows
constructing most of an essential package set and (unlike a number of
other architectures) bootstrapping tilegx works fairly well.  Debian has
a number of source-only ports and tilegx is now one of them.

That said, nobody has taken up the work to proceed a native bootstrap.
Like with nios2, progress is stalled, because the tooling for fully
automating the native phase is missing.

In any case, I won't be able to fix binutils/gcc/glibc/linux issues with
tilegx. So unless someone steps up to do that work, I won't object to
dropping it. It would be sad to see tilegx go, but it certainly isn't my
core interest either.

I'd appreciate a note if it gets dropped from any of these, because I'd
clean up outstanding bug reports then.

The reverse is also true: If you want to see an new architecture in
Debian, I also appreciate an early conversation to avoid duplicating
work.

Hope this helps

Helmut

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

[Arnd Bergmann]

On Wed, Mar 7, 2018 at 7:14 PM, Helmut Grohne <helmut@subdivi.de> wrote:
> On Wed, Mar 07, 2018 at 04:39:47PM +0100, Arnd Bergmann wrote:
>> - Helmut Grohne has done the work to add tile-gx to debian
>>    rebootstrap, and send several patches, as seen in
>>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823167
>>    However, I could find no information on this actually
>>    being turned into a full port, or anyone still actively involved
>>    in it. The Debian rebootstrap page at
>>    https://wiki.debian.org/HelmutGrohne/rebootstrap
>>    mentions lots of other architectures, but not this one.
>
> I happened help tilegx, because Adrian found someone with hw and tilegx
> appeared to be very well maintained upstream. Very little needed to be
> done to make it work in Debian. The patches I sent were pretty generic
> and addressed issues that most ports face. What is there allows
> constructing most of an essential package set and (unlike a number of
> other architectures) bootstrapping tilegx works fairly well.  Debian has
> a number of source-only ports and tilegx is now one of them.
>
> That said, nobody has taken up the work to proceed a native bootstrap.
> Like with nios2, progress is stalled, because the tooling for fully
> automating the native phase is missing.
>
> In any case, I won't be able to fix binutils/gcc/glibc/linux issues with
> tilegx. So unless someone steps up to do that work, I won't object to
> dropping it. It would be sad to see tilegx go, but it certainly isn't my
> core interest either.
>
> I'd appreciate a note if it gets dropped from any of these, because I'd
> clean up outstanding bug reports then.

I originally helped get tile, blackfin, metag, unicore32 and score into
the kernel, and it's always sad to see them go away after all the work
that was put into making them work. Out of the above, tile was
probably the best supported, and the most ambitious architecture
design, but in the end it seems it is just as dead as the others, so
I'll now add a patch to remove it along with the others in linux-4.17.

Thanks for providing some more background, that definitely helped
make the decision easier. The other point that I found is that the
Mikrotik CCR hardware is from 2012 when tilegx was still fairly
new, and if nobody has done a full port in the first six years of the
product life-cycle, it seems very unlikely to change before the CCR
itself becomes obsolete.

> The reverse is also true: If you want to see an new architecture in
> Debian, I also appreciate an early conversation to avoid duplicating
> work.

I checked the list of architectures in rebootstrap, and besides tile,
no other is currently in danger of being removed. There are however
a couple things I'd note:

- The openrisc debian port was "declared dead" a few years ago
  due to copyright issues. These are apparently getting addressed
  now at least for gcc (I know nothing about the glibc problems or
  any work on solutions). This might come back soon, but at
  the same time my impression is that the OpenRISC community
  is shrinking due to RISC-V replacing it in many new projects.

- The latest architecture to get merged into linux (also 4.17) is
  nds32. I'm meeting the maintainer (Greentime Hu) next week
  and will ask him about whether they are interested in a Debian
  port. nds32 is widely deployed in certain markets today, but the
  latest Andestech CPUs are RISC-V based, so it's also unclear
  whether this one has a long-term future.

- sh3/sh4 looked like they would get revived a few years ago
  for the j-core project. The 2015 roadmap on
  http://j-core.org/roadmap.html had ambitious plans for
  an sh3 compatible core in 2017 and an sh4 compatible one
  in 2018. However, not much has happened  at all since 2016,
  and now the website is down as well. You might want to
  contact the j-core developers for clarification.
  I suspect this has also become a victim of the RISC-V
  success.

- arm64be has some active users, and is supported in the toolchain
  and by most arm64 hardware (notably not those using UEFI to
  boot IIRC).

- riscv32 is not yet supported by Linux or glibc, but that seems
  very likely to come in the future, maybe one or two years from
  now.

       Arnd

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

[John Paul Adrian Glaubitz]

On 03/08/2018 04:55 PM, Arnd Bergmann wrote:
> I originally helped get tile, blackfin, metag, unicore32 and score into
> the kernel, and it's always sad to see them go away after all the work
> that was put into making them work. Out of the above, tile was
> probably the best supported, and the most ambitious architecture
> design, but in the end it seems it is just as dead as the others, so
> I'll now add a patch to remove it along with the others in linux-4.17.

Out of curiosity: Is there any reason why the removal of tilegx is now
being rushed? Did any of the policies regarding architectures in the
kernel change? I had the impression that architectures could previously
stay unmaintained for a while before being removed.

> - sh3/sh4 looked like they would get revived a few years ago
>    for the j-core project. The 2015 roadmap on
>    http://j-core.org/roadmap.html had ambitious plans for
>    an sh3 compatible core in 2017 and an sh4 compatible one
>    in 2018. However, not much has happened  at all since 2016,
>    and now the website is down as well. You might want to
>    contact the j-core developers for clarification.
>    I suspect this has also become a victim of the RISC-V
>    success.

Well, that's quite a bummer. I don't know what Rich Felker's and
Rob Landley's plans now are. Rich told that he would be doing paid
SH work again in the upcoming weeks. I even sent him and Rob SH4
hardware to support their efforts.

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 :(.

I will get in touch with Rich and Rob to figure out what's going
on.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Arnd Bergmann]

On Thu, Mar 8, 2018 at 5:06 PM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On 03/08/2018 04:55 PM, Arnd Bergmann wrote:
>>
>> I originally helped get tile, blackfin, metag, unicore32 and score into
>> the kernel, and it's always sad to see them go away after all the work
>> that was put into making them work. Out of the above, tile was
>> probably the best supported, and the most ambitious architecture
>> design, but in the end it seems it is just as dead as the others, so
>> I'll now add a patch to remove it along with the others in linux-4.17.
>
>
> Out of curiosity: Is there any reason why the removal of tilegx is now
> being rushed? Did any of the policies regarding architectures in the
> kernel change? I had the impression that architectures could previously
> stay unmaintained for a while before being removed.

No, nothing changed, we're normally just really bad at identifying
stuff that can go away exactly because that is the kind of thing
that nobody cares about any more.

I picked up the task to remove some of the stale architectures after
building a set of cross-compilers and noticing that some architectures
(score, unicore32, metag) are not supported by mainline gcc.

This has led me to a few more that I'm now removing after
making sure that nobody still wants them: m32r, frv, mn10300,
blackfin, cris and tile. I was planning to give some of these a
few more releases before removing them, but after talking with
the people that worked on them, the answer was always that
it's sad to let them go, but there is really no reason to keep
them.

I definitely hope that I did my research well, but if you can think
of any remaining users of upstream kernels that I missed, then
please let me know and I'll hold off on the removal for that
architecture.

The reason I want to do them all at once is that it takes a bit
of work to find all the architecture specific code in the kernel
outside of the arch/ directory, and removing nine architectures
at once makes that process much more efficient overall.

>> - sh3/sh4 looked like they would get revived a few years ago
>>    for the j-core project. The 2015 roadmap on
>>    http://j-core.org/roadmap.html had ambitious plans for
>>    an sh3 compatible core in 2017 and an sh4 compatible one
>>    in 2018. However, not much has happened  at all since 2016,
>>    and now the website is down as well. You might want to
>>    contact the j-core developers for clarification.
>>    I suspect this has also become a victim of the RISC-V
>>    success.
>
>
> Well, that's quite a bummer. I don't know what Rich Felker's and
> Rob Landley's plans now are. Rich told that he would be doing paid
> SH work again in the upcoming weeks. I even sent him and Rob SH4
> hardware to support their efforts.
>
> 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 :(.
>
> I will get in touch with Rich and Rob to figure out what's going
> on.

Ok, thanks! I'd definitely like to know what's going on as well.

        Arnd

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

[Joseph Myers]

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 <https://sourceware.org/glibc/wiki/Release/2.27#SH>.  
Probably most could be addressed with the NaN fixes I outlined at 
<https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - 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 
<https://sourceware.org/glibc/wiki/Release/2.27#MicroBlaze> 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

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

[John Paul Adrian Glaubitz]

On 03/09/2018 05:31 PM, Joseph Myers wrote:
> Note that SH glibc test results need some work - there are a large number 
> of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.  
> Probably most could be addressed with the NaN fixes I outlined at 
> <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - 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.)

Ok, thanks for the explanation.

On a sidenote: Is there documentation somewhere which explains how to properly
run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
for m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Joseph Myers]

On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote:

> On 03/09/2018 05:31 PM, Joseph Myers wrote:
> > Note that SH glibc test results need some work - there are a large number 
> > of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.  
> > Probably most could be addressed with the NaN fixes I outlined at 
> > <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - 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.)
> 
> Ok, thanks for the explanation.
> 
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.

"make check", or "make -k check" if you're concerned about some tests 
failing to build (e.g. the compiler running out of memory on a few large 
tests) - the testsuite should continue after execution failures, but not 
after compilation failures.  (Having previously configured with 
--prefix=/usr for the build.  And if the compiler used doesn't have 
libgcc_s and libstdc++ shared libraries in directories ld.so searches by 
default, you should copy those libraries into the glibc build directory 
before running tests.)  On a system that can handle it you'd use an 
appropriate -jN option for parallelism, but probably not on m68k.

For cross testing over SSH (when glibc is running on a system that is very 
slow running the compiler or has too little memory to do so) you need a 
shared filesystem at the same path on both the system where glibc is built 
and the system where tests will execute (probably NFS-exported from the 
build system, and it may be necessary to mount it on the test system with 
acdirmax=0,acdirmin=0 to limit any caching).  Then you can pass 
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh <host>" to make 
check.

In both cases, for very slow test systems you may wish to export 
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Palmer Dabbelt]

On Thu, 08 Mar 2018 07:55:33 PST (-0800), Arnd Bergmann wrote:
> - riscv32 is not yet supported by Linux or glibc, but that seems
>   very likely to come in the future, maybe one or two years from
>   now.

I'm hoping it'll be a lot less than a year away :).

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

[Arnd Bergmann]

On Thu, Mar 8, 2018 at 6:14 PM, Palmer Dabbelt <palmer@sifive.com> wrote:
> On Thu, 08 Mar 2018 07:55:33 PST (-0800), Arnd Bergmann wrote:
>>
>> - riscv32 is not yet supported by Linux or glibc, but that seems
>>   very likely to come in the future, maybe one or two years from
>>   now.
>
>
> I'm hoping it'll be a lot less than a year away :).

Ah, very good. For some reason I was under the impression that all
the early hardware with Linux support was 64-bit only, and the
32-bit Linux port therefore a low priority, but even better if that's
coming soon.

     Arnd

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

[Carlos O'Donell]

On 12/01/2017 01:34 PM, Chris Metcalf wrote:
> I will in any case be dropping off the glibc list (other than perhaps
> occasionally reading the archives) at the end of next week.  It's been
> a rewarding experience following glibc's development over the last six
> years and I will certainly miss being part of this community.
> 
> I'm keeping that libc.so.6 sticker I got from Carlos, though!  :)
 
Thank you for all of your contributions!

You made glibc better in many more ways than just those tile contributions.

A sticker is the smallest token of our appreciation that we can give.

If you change laptops, please email me, and I'll send you out a new sticker :-)

-- 
Cheers,
Carlos.

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

[Chris Metcalf]

Good bye to all - I realize I did not include my contact information,
should it be useful for some reason to reach me after today.  You
can email me at

   metcalf@alum.mit.edu

Thanks and bye!
Chris

On 12/1/2017 4:34 PM, Chris Metcalf wrote:
> The tile architecture was introduced to glibc in 2011 and first
> appeared in glibc 2.15.  The chip family of TILEPro and TILE-Gx was
> developed by Tilera, which was eventually acquired by Mellanox. Now
> at Mellanox we are developing new chips based on the ARM64
> architecture; our last TILE-Gx chip (the Gx72) was released in 2013,
> and our customers using the tile architecture products are now all in
> maintenance mode, as far as we know, and not looking to upgrade their
> software to newer open-source releases.
>
> Compounding this state of affairs is the fact that after twelve years
> here I am moving on next week; my last day at Mellanox is December
> 8th.  Since tracking upstream development of the old tile architecture
> is not a high priority for Mellanox, reasonably enough, it seems
> cleanest at this point to propose removal of the architecture from the
> glibc tree, so that the 2.26 release will be the last release to have
> tile support.
>
> 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.
>
> I will in any case be dropping off the glibc list (other than perhaps
> occasionally reading the archives) at the end of next week.  It's been
> a rewarding experience following glibc's development over the last six
> years and I will certainly miss being part of this community.
>
> I'm keeping that libc.so.6 sticker I got from Carlos, though!  :)
>

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

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

[Henrik Grindal Bakken]

Chris Metcalf <cmetcalf@mellanox.com> writes:

> The tile architecture was introduced to glibc in 2011 and first
> appeared in glibc 2.15.  The chip family of TILEPro and TILE-Gx was
> developed by Tilera, which was eventually acquired by Mellanox.  Now
> at Mellanox we are developing new chips based on the ARM64
> architecture; our last TILE-Gx chip (the Gx72) was released in 2013,
> and our customers using the tile architecture products are now all in
> maintenance mode, as far as we know, and not looking to upgrade their
> software to newer open-source releases.

At Cisco, we use TILE-Gx in current products, and we (try to) keep up to
date with new releases of both gcc and glibc (sadly not the kernel,
which has a large vendor patch).  We'd love to see the architecture
still being supported, although I don't think it would be the end of the
world if it didn't.

> 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 don't we have anyone capable of stepping up as maintainer, though.

-- 
Henrik Grindal Bakken <hgb@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52