From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20850 invoked by alias); 26 May 2005 23:25:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 20809 invoked by uid 22791); 26 May 2005 23:25:29 -0000 Received: from smtpout04-04.prod.mesa1.secureserver.net (HELO smtpout04-04.prod.mesa1.secureserver.net) (64.202.165.199) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Thu, 26 May 2005 23:25:29 +0000 Received: (qmail 4764 invoked from network); 26 May 2005 23:25:28 -0000 Received: from unknown (24.96.113.81) by smtpout04-04.prod.mesa1.secureserver.net (64.202.165.199) with ESMTP; 26 May 2005 23:25:27 -0000 Message-ID: <42965AAD.9050800@coyotegulch.com> Date: Fri, 27 May 2005 00:05:00 -0000 From: Scott Robert Ladd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050512) MIME-Version: 1.0 To: Richard Henderson CC: gcc@gcc.gnu.org Subject: Re: Sine and Cosine Accuracy References: <4295DE66.2050701@coyotegulch.com> <20050526154754.GA10785@redhat.com> <4295F374.6070901@coyotegulch.com> <20050526202626.GA11741@redhat.com> In-Reply-To: <20050526202626.GA11741@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg01462.txt.bz2 Richard Henderson wrote: > On Thu, May 26, 2005 at 12:04:04PM -0400, Scott Robert Ladd wrote: > >>I've never quite understood the necessity for performing trig operations >>on excessively large values, but perhaps my problem domain hasn't >>included such applications. > > > Whether you think it necessary or not, the ISO C functions allow > such arguments, and we're not allowed to break that without cause. Then, as someone else said, why doesn't the compiler enforce -ansi and/or -pedantic by default? Or is ANSI purity only important in some cases, but not others? I do not and have not suggested changing the default behavior of the compiler, and *have* suggested that it is not pedantic enough about Standards. *This* discussion is about improving -funsafe-math-optimizations to make it more sensible and flexible. For a wide variety of applications, the hardware intrinsics provide both faster and more accurate results, when compared to the library functions. However, I may *not* want other transformations implied by -funsafe-math-optimizations. Therefore, it seems to me that GCC could cleanly and simply implement an option to use hardware intrinsics (or a highly-optimized but non-ANSI library) for those of us who want it. No changes to default optimizations, no breaking of existing code, just a new option (as in optional.) How does that hurt you or anyone else? It's not as if GCC doesn't have a few options already... ;) I (and others) also note other compilers do a fine job of handling these problems. ..Scott