From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14224 invoked by alias); 26 May 2005 18:30:30 -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 14181 invoked by uid 22791); 26 May 2005 18:30:23 -0000 Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 26 May 2005 18:30:23 +0000 Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 19:30:22 +0100 From: "Dave Korn" To: "'Scott Robert Ladd'" Cc: "'Morten Welinder'" , Subject: RE: Sine and Cosine Accuracy Date: Thu, 26 May 2005 19:28:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <429610BC.9050408@coyotegulch.com> Message-ID: X-SW-Source: 2005-05/txt/msg01447.txt.bz2 ----Original Message---- >From: Scott Robert Ladd >Sent: 26 May 2005 19:09 > Dave Korn wrote: >> Well, as long as they're under the control of a flag that also makes it >> clear that they are *also* unsafe math optimisations, I wouldn't object. > > But they are *not* unsafe for *all* applications. Irrelevant; nor are many of the other things that are described by the term unsafe. In fact they are often things that may be safe on one occasion, yet not on another, even within one single application. Referring to something as "unsafe" doesn't mean it's *always* unsafe, but referring to it as safe (or implying that it is by contrast with an option that names it as unsafe) *does* mean that it is *always* safe. > An ignorant user may not understand the ramifications of "unsafe" math > -- however, the current documentation is quite vague as to why these > optimizations are unsafe, and people thus become paranoid and avoid > -ffast-math when it would be to their benefit. Until they get sqrt(-1.0) returning a value of +1.0 with no complaints, of course.... But yes: the biggest problem here that I can see is inadequate documentation. > First and foremost, GCC should conform to standards. *However*, I see > nothing wrong with providing additional capability for those who need > it, without combining everything "unsafe" under one umbrella. That's exactly what I said up at the top. Nothing wrong with having multiple unsafe options, but they *are* all unsafe. >> But you can't just replace a call to the ANSI C 'sin' function with an >> invocation of the x87 fsin intrinsic, because they aren't the same, and >> the intrinsic is non-ansi-compliant. > > Nobody said they were. Then any optimisation flag that replaces one with the other is, QED, unsafe. Of course, if you went and wrote a whole load of builtins, so that with your new flag in effect "sin (x)" would translate into a code sequence that first uses fmod to reduce the argument to the valid range for fsin, I would no longer consider it unsafe. cheers, DaveK -- Can't think of a witty .sigline today....