* 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 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-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 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 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: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-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 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 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: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: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-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: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 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
* 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-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
* 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
[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: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: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: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: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: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: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
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
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 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
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
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).