From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2931 invoked by alias); 29 Apr 2013 14:02:10 -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 2910 invoked by uid 89); 29 Apr 2013 14:02:10 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mail-wg0-f54.google.com (HELO mail-wg0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 29 Apr 2013 14:02:09 +0000 Received: by mail-wg0-f54.google.com with SMTP id y10so3611742wgg.21 for ; Mon, 29 Apr 2013 07:02:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.166 with SMTP id i6mr18108941wic.21.1367244127087; Mon, 29 Apr 2013 07:02:07 -0700 (PDT) Received: by 10.194.220.39 with HTTP; Mon, 29 Apr 2013 07:02:06 -0700 (PDT) In-Reply-To: References: <20130429102739.GE1330@spoyarek.pnq.redhat.com> Date: Mon, 29 Apr 2013 14:02:00 -0000 Message-ID: Subject: Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos From: Siddhesh Poyarekar To: "Joseph S. Myers" Cc: Siddhesh Poyarekar , GNU C Library , libc-ports@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-04/txt/msg00107.txt.bz2 On 29 April 2013 19:04, Joseph S. Myers 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