This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: remove the "tile" architecture from glibc
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- 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 15:20:54 -0200
- Subject: Re: RFC: remove the "tile" architecture from glibc
- Authentication-results: sourceware.org; auth=none
- References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <d6c8e425-a6b6-6594-05e3-965536f06da3@physik.fu-berlin.de> <alpine.DEB.2.20.1712012159490.15078@digraph.polyomino.org.uk> <995aac59-2f9d-2a6a-2b5c-b827410ad295@physik.fu-berlin.de> <alpine.DEB.2.20.1801311732001.23883@digraph.polyomino.org.uk> <38170271-e17f-0a7e-7dd2-06fa6ddfae62@physik.fu-berlin.de> <9f8b994a-7085-e263-dd1b-bea2def55fb0@linaro.org> <0ebe0678-1eab-16ba-c461-2cfe517189bb@linaro.org> <alpine.DEB.2.20.1802011329550.7786@digraph.polyomino.org.uk>
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).
>