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

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

**Follow-Ups**:**Re: RFC: remove the "tile" architecture from glibc***From:*Joseph Myers

**Re: RFC: remove the "tile" architecture from glibc***From:*Joseph Myers

**References**:**Re: RFC: remove the "tile" architecture from glibc***From:*Adhemerval Zanella

**Re: RFC: remove the "tile" architecture from glibc***From:*Joseph Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |