This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos
- From: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, libc-ports at sourceware dot org
- Date: Mon, 29 Apr 2013 19:32:06 +0530
- Subject: Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos
- References: <20130429102739 dot GE1330 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1304291332320 dot 10827 at digraph dot polyomino dot org dot uk>
On 29 April 2013 19:04, Joseph S. Myers <joseph@codesourcery.com> wrote:
> The changes don't seem to include accurate range reduction. Without that,
> I think this is inappropriate, as it will result in wildly inaccurate
> results for large but finite inputs.
Right, I had overlooked that in my earlier submission.
> (I've stated before that all libm tests with finite inputs and outputs
> should be run with -ffinite-math-only - and I consider that they should
> pass when they pass without that option, and should not need different
> ulps for the different ways of running them.)
I wonder if this is a valid case for _fast implementations distinct
from the default implementation. gcc could define a macro
(__FAST_MATH__ or similar) when called with -ffast-math. This gives
us the necessary fast and not-so-accurate implementations that a lot
of people seem to want. I had assumed that __FINITE_MATH_ONLY__ was
the right place for it, but Andreas pointed out that by definition, it
is not.
Siddhesh
--
http://siddhesh.in