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