This is the mail archive of the
mailing list for the glibc project.
Re: RFC: remove the "tile" architecture from glibc
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: <libc-alpha at sourceware dot org>, Jason Duerstock <jason dot duerstock at gmail dot com>, John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin dot de>, James Clarke <jrtc27 at jrtc27 dot com>
- Date: Thu, 1 Feb 2018 13:39:04 +0000
- Subject: Re: RFC: remove the "tile" architecture from glibc
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <alpine.DEB.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
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
(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