* RFC: remove the "tile" architecture from glibc @ 2017-12-01 21:34 Chris Metcalf 2017-12-01 21:41 ` Joseph Myers ` (4 more replies) 0 siblings, 5 replies; 51+ messages in thread From: Chris Metcalf @ 2017-12-01 21:34 UTC (permalink / raw) To: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf @ 2017-12-01 21:41 ` Joseph Myers 2017-12-01 21:57 ` John Paul Adrian Glaubitz ` (3 subsequent siblings) 4 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2017-12-01 21:41 UTC (permalink / raw) To: Chris Metcalf; +Cc: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf 2017-12-01 21:41 ` Joseph Myers @ 2017-12-01 21:57 ` John Paul Adrian Glaubitz 2017-12-01 22:11 ` Joseph Myers 2017-12-02 1:15 ` Chris Metcalf 2017-12-02 3:24 ` Carlos O'Donell ` (2 subsequent siblings) 4 siblings, 2 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-01 21:57 UTC (permalink / raw) To: Chris Metcalf; +Cc: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:57 ` John Paul Adrian Glaubitz @ 2017-12-01 22:11 ` Joseph Myers 2017-12-01 22:30 ` John Paul Adrian Glaubitz 2017-12-02 1:15 ` Chris Metcalf 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2017-12-01 22:11 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: Chris Metcalf, GNU C Library [-- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 22:11 ` Joseph Myers @ 2017-12-01 22:30 ` John Paul Adrian Glaubitz 2017-12-01 22:41 ` Joseph Myers [not found] ` <alpine.DEB.2.20.1801311732001.23883@digraph.polyomino.org.uk> 0 siblings, 2 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-01 22:30 UTC (permalink / raw) To: Joseph Myers; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 22:30 ` John Paul Adrian Glaubitz @ 2017-12-01 22:41 ` Joseph Myers 2017-12-02 15:15 ` John Paul Adrian Glaubitz [not found] ` <alpine.DEB.2.20.1801311732001.23883@digraph.polyomino.org.uk> 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2017-12-01 22:41 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 22:41 ` Joseph Myers @ 2017-12-02 15:15 ` John Paul Adrian Glaubitz 2017-12-04 11:10 ` Adhemerval Zanella 2017-12-04 17:53 ` Joseph Myers 0 siblings, 2 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-02 15:15 UTC (permalink / raw) To: Joseph Myers; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-02 15:15 ` John Paul Adrian Glaubitz @ 2017-12-04 11:10 ` Adhemerval Zanella 2017-12-04 11:28 ` John Paul Adrian Glaubitz ` (2 more replies) 2017-12-04 17:53 ` Joseph Myers 1 sibling, 3 replies; 51+ messages in thread From: Adhemerval Zanella @ 2017-12-04 11:10 UTC (permalink / raw) To: libc-alpha; +Cc: John Paul Adrian Glaubitz 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 11:10 ` Adhemerval Zanella @ 2017-12-04 11:28 ` John Paul Adrian Glaubitz 2017-12-04 18:03 ` Joseph Myers 2017-12-04 18:14 ` Chris Metcalf 2 siblings, 0 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-04 11:28 UTC (permalink / raw) To: Adhemerval Zanella, libc-alpha, Jason Duerstock 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 11:10 ` Adhemerval Zanella 2017-12-04 11:28 ` John Paul Adrian Glaubitz @ 2017-12-04 18:03 ` Joseph Myers 2017-12-04 18:32 ` Adhemerval Zanella 2017-12-04 18:14 ` Chris Metcalf 2 siblings, 1 reply; 51+ messages in thread From: Joseph Myers @ 2017-12-04 18:03 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha, John Paul Adrian Glaubitz 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 18:03 ` Joseph Myers @ 2017-12-04 18:32 ` Adhemerval Zanella 2017-12-04 18:55 ` Joseph Myers 0 siblings, 1 reply; 51+ messages in thread From: Adhemerval Zanella @ 2017-12-04 18:32 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha, John Paul Adrian Glaubitz 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 18:32 ` Adhemerval Zanella @ 2017-12-04 18:55 ` Joseph Myers 0 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2017-12-04 18:55 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha, John Paul Adrian Glaubitz 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 11:10 ` Adhemerval Zanella 2017-12-04 11:28 ` John Paul Adrian Glaubitz 2017-12-04 18:03 ` Joseph Myers @ 2017-12-04 18:14 ` Chris Metcalf 2017-12-04 18:36 ` Adhemerval Zanella 2 siblings, 1 reply; 51+ messages in thread From: Chris Metcalf @ 2017-12-04 18:14 UTC (permalink / raw) To: Adhemerval Zanella, libc-alpha; +Cc: John Paul Adrian Glaubitz 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 18:14 ` Chris Metcalf @ 2017-12-04 18:36 ` Adhemerval Zanella 0 siblings, 0 replies; 51+ messages in thread From: Adhemerval Zanella @ 2017-12-04 18:36 UTC (permalink / raw) To: Chris Metcalf, libc-alpha; +Cc: John Paul Adrian Glaubitz 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. > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-02 15:15 ` John Paul Adrian Glaubitz 2017-12-04 11:10 ` Adhemerval Zanella @ 2017-12-04 17:53 ` Joseph Myers 2017-12-04 18:47 ` John Paul Adrian Glaubitz 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2017-12-04 17:53 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 17:53 ` Joseph Myers @ 2017-12-04 18:47 ` John Paul Adrian Glaubitz 2017-12-04 19:02 ` Joseph Myers 0 siblings, 1 reply; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-04 18:47 UTC (permalink / raw) To: Joseph Myers; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 18:47 ` John Paul Adrian Glaubitz @ 2017-12-04 19:02 ` Joseph Myers 0 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2017-12-04 19:02 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: Chris Metcalf, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
[parent not found: <alpine.DEB.2.20.1801311732001.23883@digraph.polyomino.org.uk>]
[parent not found: <38170271-e17f-0a7e-7dd2-06fa6ddfae62@physik.fu-berlin.de>]
[parent not found: <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org>]
* Re: RFC: remove the "tile" architecture from glibc [not found] ` <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org> @ 2018-02-01 13:24 ` Adhemerval Zanella 2018-02-01 13:33 ` John Paul Adrian Glaubitz 2018-02-01 13:39 ` Joseph Myers 2018-02-14 18:13 ` Joseph Myers 1 sibling, 2 replies; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 13:24 UTC (permalink / raw) To: libc-alpha; +Cc: Jason Duerstock, John Paul Adrian Glaubitz, James Clarke 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:24 ` Adhemerval Zanella @ 2018-02-01 13:33 ` John Paul Adrian Glaubitz 2018-02-01 13:37 ` Adhemerval Zanella 2018-02-01 13:39 ` Joseph Myers 1 sibling, 1 reply; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2018-02-01 13:33 UTC (permalink / raw) To: Adhemerval Zanella, libc-alpha; +Cc: Jason Duerstock, James Clarke 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:33 ` John Paul Adrian Glaubitz @ 2018-02-01 13:37 ` Adhemerval Zanella 2018-02-01 13:45 ` Joseph Myers 0 siblings, 1 reply; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 13:37 UTC (permalink / raw) To: John Paul Adrian Glaubitz, libc-alpha; +Cc: Jason Duerstock, James Clarke 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:37 ` Adhemerval Zanella @ 2018-02-01 13:45 ` Joseph Myers 2018-02-01 16:40 ` Adhemerval Zanella 0 siblings, 1 reply; 51+ messages in thread From: Joseph Myers @ 2018-02-01 13:45 UTC (permalink / raw) To: Adhemerval Zanella Cc: John Paul Adrian Glaubitz, libc-alpha, Jason Duerstock, James Clarke 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:45 ` Joseph Myers @ 2018-02-01 16:40 ` Adhemerval Zanella 0 siblings, 0 replies; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 16:40 UTC (permalink / raw) To: Joseph Myers Cc: John Paul Adrian Glaubitz, libc-alpha, Jason Duerstock, James Clarke 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:24 ` Adhemerval Zanella 2018-02-01 13:33 ` John Paul Adrian Glaubitz @ 2018-02-01 13:39 ` Joseph Myers 2018-02-01 17:21 ` Adhemerval Zanella 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2018-02-01 13:39 UTC (permalink / raw) To: Adhemerval Zanella Cc: libc-alpha, Jason Duerstock, John Paul Adrian Glaubitz, James Clarke 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:39 ` Joseph Myers @ 2018-02-01 17:21 ` Adhemerval Zanella 2018-02-01 17:52 ` Joseph Myers 2018-02-01 18:30 ` Joseph Myers 0 siblings, 2 replies; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 17:21 UTC (permalink / raw) To: Joseph Myers Cc: libc-alpha, Jason Duerstock, John Paul Adrian Glaubitz, James Clarke 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). > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 17:21 ` Adhemerval Zanella @ 2018-02-01 17:52 ` Joseph Myers 2018-02-01 18:30 ` Joseph Myers 1 sibling, 0 replies; 51+ messages in thread From: Joseph Myers @ 2018-02-01 17:52 UTC (permalink / raw) To: Adhemerval Zanella Cc: libc-alpha, Jason Duerstock, John Paul Adrian Glaubitz, James Clarke 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 17:21 ` Adhemerval Zanella 2018-02-01 17:52 ` Joseph Myers @ 2018-02-01 18:30 ` Joseph Myers 1 sibling, 0 replies; 51+ messages in thread From: Joseph Myers @ 2018-02-01 18:30 UTC (permalink / raw) To: Adhemerval Zanella Cc: libc-alpha, Jason Duerstock, John Paul Adrian Glaubitz, James Clarke 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc [not found] ` <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org> 2018-02-01 13:24 ` Adhemerval Zanella @ 2018-02-14 18:13 ` Joseph Myers 1 sibling, 0 replies; 51+ messages in thread From: Joseph Myers @ 2018-02-14 18:13 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc [not found] ` <38170271-e17f-0a7e-7dd2-06fa6ddfae62@physik.fu-berlin.de> [not found] ` <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org> @ 2018-02-01 13:34 ` Adhemerval Zanella 2018-02-01 13:50 ` Joseph Myers 1 sibling, 1 reply; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 13:34 UTC (permalink / raw) To: libc-alpha 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:34 ` Adhemerval Zanella @ 2018-02-01 13:50 ` Joseph Myers 2018-02-01 16:50 ` Adhemerval Zanella 0 siblings, 1 reply; 51+ messages in thread From: Joseph Myers @ 2018-02-01 13:50 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha [-- 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-02-01 13:50 ` Joseph Myers @ 2018-02-01 16:50 ` Adhemerval Zanella 0 siblings, 0 replies; 51+ messages in thread From: Adhemerval Zanella @ 2018-02-01 16:50 UTC (permalink / raw) To: Joseph Myers; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:57 ` John Paul Adrian Glaubitz 2017-12-01 22:11 ` Joseph Myers @ 2017-12-02 1:15 ` Chris Metcalf 2017-12-02 15:16 ` John Paul Adrian Glaubitz 1 sibling, 1 reply; 51+ messages in thread From: Chris Metcalf @ 2017-12-02 1:15 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-02 1:15 ` Chris Metcalf @ 2017-12-02 15:16 ` John Paul Adrian Glaubitz 2017-12-04 21:49 ` Chris Metcalf 2018-03-07 15:39 ` Arnd Bergmann 0 siblings, 2 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2017-12-02 15:16 UTC (permalink / raw) To: Chris Metcalf; +Cc: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-02 15:16 ` John Paul Adrian Glaubitz @ 2017-12-04 21:49 ` Chris Metcalf 2017-12-04 23:29 ` Joseph Myers 2018-03-07 15:39 ` Arnd Bergmann 1 sibling, 1 reply; 51+ messages in thread From: Chris Metcalf @ 2017-12-04 21:49 UTC (permalink / raw) To: John Paul Adrian Glaubitz; +Cc: GNU C Library, Joseph Myers 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-04 21:49 ` Chris Metcalf @ 2017-12-04 23:29 ` Joseph Myers 0 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2017-12-04 23:29 UTC (permalink / raw) To: Chris Metcalf; +Cc: John Paul Adrian Glaubitz, GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-02 15:16 ` John Paul Adrian Glaubitz 2017-12-04 21:49 ` Chris Metcalf @ 2018-03-07 15:39 ` Arnd Bergmann 2018-03-07 16:01 ` Joseph Myers 2018-03-07 18:16 ` Helmut Grohne 1 sibling, 2 replies; 51+ messages in thread From: Arnd Bergmann @ 2018-03-07 15:39 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List, Helmut Grohne 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 15:39 ` Arnd Bergmann @ 2018-03-07 16:01 ` Joseph Myers 2018-03-07 16:08 ` John Paul Adrian Glaubitz 2018-03-07 18:16 ` Helmut Grohne 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2018-03-07 16:01 UTC (permalink / raw) To: Arnd Bergmann Cc: John Paul Adrian Glaubitz, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List, Helmut Grohne 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 16:01 ` Joseph Myers @ 2018-03-07 16:08 ` John Paul Adrian Glaubitz 2018-03-07 16:49 ` Adhemerval Zanella 0 siblings, 1 reply; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2018-03-07 16:08 UTC (permalink / raw) To: Joseph Myers, Arnd Bergmann Cc: GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List, Helmut Grohne 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 16:08 ` John Paul Adrian Glaubitz @ 2018-03-07 16:49 ` Adhemerval Zanella 2018-03-07 17:17 ` Joseph Myers 0 siblings, 1 reply; 51+ messages in thread From: Adhemerval Zanella @ 2018-03-07 16:49 UTC (permalink / raw) To: libc-alpha 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 > ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 16:49 ` Adhemerval Zanella @ 2018-03-07 17:17 ` Joseph Myers 0 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2018-03-07 17:17 UTC (permalink / raw) To: Adhemerval Zanella; +Cc: libc-alpha 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 15:39 ` Arnd Bergmann 2018-03-07 16:01 ` Joseph Myers @ 2018-03-07 18:16 ` Helmut Grohne 2018-03-08 15:55 ` Arnd Bergmann 1 sibling, 1 reply; 51+ messages in thread From: Helmut Grohne @ 2018-03-07 18:16 UTC (permalink / raw) To: Arnd Bergmann Cc: John Paul Adrian Glaubitz, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-07 18:16 ` Helmut Grohne @ 2018-03-08 15:55 ` Arnd Bergmann 2018-03-08 16:06 ` John Paul Adrian Glaubitz 2018-03-08 17:14 ` Palmer Dabbelt 0 siblings, 2 replies; 51+ messages in thread From: Arnd Bergmann @ 2018-03-08 15:55 UTC (permalink / raw) To: Helmut Grohne, Arnd Bergmann, John Paul Adrian Glaubitz, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-08 15:55 ` Arnd Bergmann @ 2018-03-08 16:06 ` John Paul Adrian Glaubitz 2018-03-08 16:23 ` Arnd Bergmann 2018-03-09 16:31 ` Joseph Myers 2018-03-08 17:14 ` Palmer Dabbelt 1 sibling, 2 replies; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2018-03-08 16:06 UTC (permalink / raw) To: Arnd Bergmann, Helmut Grohne, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-08 16:06 ` John Paul Adrian Glaubitz @ 2018-03-08 16:23 ` Arnd Bergmann 2018-03-09 16:31 ` Joseph Myers 1 sibling, 0 replies; 51+ messages in thread From: Arnd Bergmann @ 2018-03-08 16:23 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Helmut Grohne, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-08 16:06 ` John Paul Adrian Glaubitz 2018-03-08 16:23 ` Arnd Bergmann @ 2018-03-09 16:31 ` Joseph Myers 2018-03-09 16:37 ` John Paul Adrian Glaubitz 1 sibling, 1 reply; 51+ messages in thread From: Joseph Myers @ 2018-03-09 16:31 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Arnd Bergmann, Helmut Grohne, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-09 16:31 ` Joseph Myers @ 2018-03-09 16:37 ` John Paul Adrian Glaubitz 2018-03-09 16:53 ` Joseph Myers 0 siblings, 1 reply; 51+ messages in thread From: John Paul Adrian Glaubitz @ 2018-03-09 16:37 UTC (permalink / raw) To: Joseph Myers Cc: Arnd Bergmann, Helmut Grohne, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-09 16:37 ` John Paul Adrian Glaubitz @ 2018-03-09 16:53 ` Joseph Myers 0 siblings, 0 replies; 51+ messages in thread From: Joseph Myers @ 2018-03-09 16:53 UTC (permalink / raw) To: John Paul Adrian Glaubitz Cc: Arnd Bergmann, Helmut Grohne, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-08 15:55 ` Arnd Bergmann 2018-03-08 16:06 ` John Paul Adrian Glaubitz @ 2018-03-08 17:14 ` Palmer Dabbelt 2018-03-08 23:36 ` Arnd Bergmann 1 sibling, 1 reply; 51+ messages in thread From: Palmer Dabbelt @ 2018-03-08 17:14 UTC (permalink / raw) To: Arnd Bergmann Cc: helmut, Arnd Bergmann, glaubitz, libc-alpha, linux-arch, metcalf, hgb, linux-kernel 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 :). ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2018-03-08 17:14 ` Palmer Dabbelt @ 2018-03-08 23:36 ` Arnd Bergmann 0 siblings, 0 replies; 51+ messages in thread From: Arnd Bergmann @ 2018-03-08 23:36 UTC (permalink / raw) To: Palmer Dabbelt Cc: Helmut Grohne, John Paul Adrian Glaubitz, GNU C Library, linux-arch, metcalf, Henrik Grindal Bakken, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf 2017-12-01 21:41 ` Joseph Myers 2017-12-01 21:57 ` John Paul Adrian Glaubitz @ 2017-12-02 3:24 ` Carlos O'Donell 2017-12-08 16:20 ` Chris Metcalf 2018-01-05 9:01 ` Henrik Grindal Bakken 4 siblings, 0 replies; 51+ messages in thread From: Carlos O'Donell @ 2017-12-02 3:24 UTC (permalink / raw) To: Chris Metcalf, GNU C Library 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. ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf ` (2 preceding siblings ...) 2017-12-02 3:24 ` Carlos O'Donell @ 2017-12-08 16:20 ` Chris Metcalf 2018-01-05 9:01 ` Henrik Grindal Bakken 4 siblings, 0 replies; 51+ messages in thread From: Chris Metcalf @ 2017-12-08 16:20 UTC (permalink / raw) To: GNU C Library 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: RFC: remove the "tile" architecture from glibc 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf ` (3 preceding siblings ...) 2017-12-08 16:20 ` Chris Metcalf @ 2018-01-05 9:01 ` Henrik Grindal Bakken 4 siblings, 0 replies; 51+ messages in thread From: Henrik Grindal Bakken @ 2018-01-05 9:01 UTC (permalink / raw) To: libc-alpha 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 ^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2018-03-09 16:53 UTC | newest] Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-01 21:34 RFC: remove the "tile" architecture from glibc Chris Metcalf 2017-12-01 21:41 ` Joseph Myers 2017-12-01 21:57 ` John Paul Adrian Glaubitz 2017-12-01 22:11 ` Joseph Myers 2017-12-01 22:30 ` John Paul Adrian Glaubitz 2017-12-01 22:41 ` Joseph Myers 2017-12-02 15:15 ` John Paul Adrian Glaubitz 2017-12-04 11:10 ` Adhemerval Zanella 2017-12-04 11:28 ` John Paul Adrian Glaubitz 2017-12-04 18:03 ` Joseph Myers 2017-12-04 18:32 ` Adhemerval Zanella 2017-12-04 18:55 ` Joseph Myers 2017-12-04 18:14 ` Chris Metcalf 2017-12-04 18:36 ` Adhemerval Zanella 2017-12-04 17:53 ` Joseph Myers 2017-12-04 18:47 ` John Paul Adrian Glaubitz 2017-12-04 19:02 ` Joseph Myers [not found] ` <alpine.DEB.2.20.1801311732001.23883@digraph.polyomino.org.uk> [not found] ` <38170271-e17f-0a7e-7dd2-06fa6ddfae62@physik.fu-berlin.de> [not found] ` <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org> 2018-02-01 13:24 ` Adhemerval Zanella 2018-02-01 13:33 ` John Paul Adrian Glaubitz 2018-02-01 13:37 ` Adhemerval Zanella 2018-02-01 13:45 ` Joseph Myers 2018-02-01 16:40 ` Adhemerval Zanella 2018-02-01 13:39 ` Joseph Myers 2018-02-01 17:21 ` Adhemerval Zanella 2018-02-01 17:52 ` Joseph Myers 2018-02-01 18:30 ` Joseph Myers 2018-02-14 18:13 ` Joseph Myers 2018-02-01 13:34 ` Adhemerval Zanella 2018-02-01 13:50 ` Joseph Myers 2018-02-01 16:50 ` Adhemerval Zanella 2017-12-02 1:15 ` Chris Metcalf 2017-12-02 15:16 ` John Paul Adrian Glaubitz 2017-12-04 21:49 ` Chris Metcalf 2017-12-04 23:29 ` Joseph Myers 2018-03-07 15:39 ` Arnd Bergmann 2018-03-07 16:01 ` Joseph Myers 2018-03-07 16:08 ` John Paul Adrian Glaubitz 2018-03-07 16:49 ` Adhemerval Zanella 2018-03-07 17:17 ` Joseph Myers 2018-03-07 18:16 ` Helmut Grohne 2018-03-08 15:55 ` Arnd Bergmann 2018-03-08 16:06 ` John Paul Adrian Glaubitz 2018-03-08 16:23 ` Arnd Bergmann 2018-03-09 16:31 ` Joseph Myers 2018-03-09 16:37 ` John Paul Adrian Glaubitz 2018-03-09 16:53 ` Joseph Myers 2018-03-08 17:14 ` Palmer Dabbelt 2018-03-08 23:36 ` Arnd Bergmann 2017-12-02 3:24 ` Carlos O'Donell 2017-12-08 16:20 ` Chris Metcalf 2018-01-05 9:01 ` Henrik Grindal Bakken
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).