From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16643 invoked by alias); 29 Apr 2013 14:16:39 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 16619 invoked by uid 89); 29 Apr 2013 14:16:38 -0000 X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_NEUTRAL autolearn=no version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from popelka.ms.mff.cuni.cz (HELO popelka.ms.mff.cuni.cz) (195.113.20.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Apr 2013 14:16:38 +0000 Received: from domone.kolej.mff.cuni.cz (popelka.ms.mff.cuni.cz [195.113.20.131]) by popelka.ms.mff.cuni.cz (Postfix) with ESMTPS id 9F9046A727; Mon, 29 Apr 2013 16:16:33 +0200 (CEST) Received: by domone.kolej.mff.cuni.cz (Postfix, from userid 1000) id 5F35C60470; Mon, 29 Apr 2013 16:15:53 +0200 (CEST) Date: Mon, 29 Apr 2013 14:16:00 -0000 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: "Joseph S. Myers" Cc: Siddhesh Poyarekar , libc-alpha@sourceware.org, libc-ports@sourceware.org Subject: Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos Message-ID: <20130429141553.GC24033@domone.kolej.mff.cuni.cz> References: <20130429102739.GE1330@spoyarek.pnq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-04/txt/msg00108.txt.bz2 On Mon, Apr 29, 2013 at 01:34:42PM +0000, Joseph S. Myers wrote: > On Mon, 29 Apr 2013, Siddhesh Poyarekar wrote: > > > This patch brings back the assembly implementation of sincos (with > > some changes) to give a fast alternative to the default sincos > > implementation. This is defined as __sincos_finite and is used if the > > implementing program is compiled with the -ffinite-math-only gcc flag. > > 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. > These inputs contain zero significant digits. You cannot expect any accuracty from them. > (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.) > > -- > Joseph S. Myers > joseph@codesourcery.com