This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 26 Apr 2013 15:07:02 +0000
- Subject: [Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions
- Auto-submitted: auto-generated
- References: <bug-14412-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=14412
--- Comment #23 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2013-04-26 15:07:02 UTC ---
It's only a limited subset of transcendental functions for which glibc is
trying to be correctly rounding, and only for double for those functions;
for most functions the aim is generally errors within "a few" ulps (and
ISO C doesn't specify particular accuracy requirements), though correctly
rounding would be some sort of ideal.
Implementing the proposed TS 18661 bindings to IEEE 754-2008 would be a
huge amount of work (and require compiler work as well), but if anyone
gets the time for that work then I believe part 4 of the draft TS will
reserve names such as crsin for correctly rounding functions (and
crsinf128 for correctly rounding sine for _Float128, etc.), without
requiring those functions, so it might make sense eventually to provide
those names for correctly-rounding functions where available without
making them the default versions. So far I'm still working on going
through the accumulated libm bugs that don't require such huge amounts of
work as DTS 18661 or ISO 24747 implementation - where one reported bug
often shows up lots of related bugs not previously in Bugzilla, that also
need to be fixed - rather than trying to find time for larger libm
projects (and I'm also mostly leaving aside libm bugs in areas where
others have shown interest in fixing them, such as performance or errno
handling).
(The present functions, producing correctly-rounded results only for
round-to-nearest, would not of course meet the requirements for functions
such as crsin, although it's probably possible to adapt them by just doing
a little bit of final arithmetic in the original rounding mode, having
done the intermediate computations to produce a higher-precision result in
round-to-nearest.)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.