From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-93299-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1866 invoked by alias); 24 Mar 2004 05:38:09 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 1824 invoked from network); 24 Mar 2004 05:38:07 -0000
Received: from unknown (HELO smtp2.fuse.net) (216.68.8.172)
  by sources.redhat.com with SMTP; 24 Mar 2004 05:38:07 -0000
Received: from dellpi.pinski.fam ([66.42.135.251]) by smtp2.fuse.net
          (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP
          id <20040324053802.BHQP29230.smtp2.fuse.net@dellpi.pinski.fam>;
          Wed, 24 Mar 2004 00:38:02 -0500
Received: from [127.0.0.1] (IDENT:pinskia@localhost.pinski.fam [127.0.0.1])
	by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id i2O5c0xj013758;
	Wed, 24 Mar 2004 00:38:01 -0500 (EST)
In-Reply-To: <20040324052059.GA12623@twcny.rr.com>
References: <20040324052059.GA12623@twcny.rr.com>
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <69F59AB2-7D55-11D8-AA55-000393A6D2F2@physics.uc.edu>
Content-Transfer-Encoding: 7bit
Cc: gcc@gcc.gnu.org, Andrew Pinski <pinskia@physics.uc.edu>
From: Andrew Pinski <pinskia@physics.uc.edu>
Subject: Re: Making -ffast-math more fine-grained?
Date: Wed, 24 Mar 2004 15:44:00 -0000
To: neroden@twcny.rr.com (Nathanael Nerode)
X-SW-Source: 2004-03/txt/msg01380.txt.bz2

I thought we have already have some of these flags already, yes we do:

On Mar 23, 2004, at 21:20, Nathanael Nerode wrote:
> 1 * Ones which allow excess precision computations (these really 
> should be OK
> for most people, though not for testsuites)

Done by default on targets which support 80bit math as faster than 
64bit would.
I do not think this is going to change any time soon.

> 2 * Ones which ignore correct behavior for anything with NaN or 
> infinities
> (and maybe -0.0 vs. +0.0) as intermediate computations, but behave
> properly with real numbers (there's probably a class of users who would
> appreciate this)

   -ffinite-math-only          Assume no NaNs or infinities are generated

> 3 * Ones which slightly reduce accuracy by doing truncations instead of
> rounding, etc., but where meaningful bounds on the accuracy can be 
> computed
> (I'm sure there's a class of users who would appreciate this)

   -frounding-math             Disable optimizations that assume default 
FP
                               rounding behavior

> 4 * Ones which only work when the exponents involved are close (and 
> are only
> useful in cases which should have been coded in fixed-point arithmetic)
> such as (a+b)+c => a+(b+c) mentioned by Robert Dewar recently, which 
> are really
> dangerous

   -funsafe-math-optimizations Allow math optimizations that may violate 
IEEE or


There are some which you missed and are unset by -ffast-math (they are 
set by defualt):
   -fmath-errno            Set errno after built-in math functions
   -fsignaling-nans        Disable optimizations observable by IEEE 
signaling NaNs
   -ftrapping-math             Assume floating-point operations can trap


/* The following routines are useful in setting all the flags that
    -ffast-math and -fno-fast-math imply.  */
void
set_fast_math_flags (int set)
{
   flag_trapping_math = !set;
   flag_unsafe_math_optimizations = set;
   flag_finite_math_only = set;
   flag_errno_math = !set;
   if (set)
     {
       flag_signaling_nans = 0;
       flag_rounding_math = 0;
     }
}

Thanks,
Andrew Pinski