This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]