------- Comment #59 from paolo dot bonzini at lu dot unisi dot ch 2006-08-10 06:52 ------- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
> Thanks for the response, but I believe you are conflating two issues (as is > this flag, which is why this is bad news). Different answers to the question > "what is this sum" does not ruin IEEE compliance. I am referring to IEEE 754, > which is a standard set of rules for storage and arithmetic for floating point > (fp) on modern hardware. You are also confusing -funsafe-math-optimizations with -ffast-math. The latter is a "one catch all" flag that compiles as if there were no FP traps, infinities, NaNs, and so on. The former instead enables "unsafe" optimizations but not "catastrophic" optimizations -- if you consider meaningless results on badly conditioned matrixes to not be catastrophic... A more or less complete list of things enabled by -funsafe-math-optimizations includes: Reassociation: - reassociation of operations, not only for the vectorizer's sake but also in the unroller (see around line 1600 of loop-unroll.c) - other simplifications like a/(b*c) for a/b/c - expansion of pow (a, b) to multiplications if b is integer Compile-time evaluation: - doing more aggressive compile-time evaluation of floating-point expressions (e.g. cabs) - less accurate modeling of overflow in compile-time expressions, for formats such as 106-bit mantissa long doubles Math identities: - expansion of cabs to sqrt (a*a + b*b) - simplifications involving trascendental functions, e.g. exp (0.5*x) for sqrt (exp (x)), or x for tan(atan(x)) - moving terms to the other side of a comparison, e.g. a > 4 for a + 4 > 8, or x > -1 for 1 - x < 2 - assuming in-domain arguments of sqrt, log, etc., e.g. x for sqrt(x)*sqrt(x) - in turn, this enables removing math functions from comparisons, e.g. x > 4 for sqrt (x) > 2 Optimization: - strength reduction of a/b to a*(1/b), both as loop invariants and in code like vector normalization - eliminating recursion for "accumulator"-like functions, i.e. f (n) = n + f(n-1) Back-end operation: - using x87 builtins for transcendental functions There may be bugs, but in general these optimizations are safe for infinities and NaNs, but not for signed zeros or (as I said) for very badly conditioned data. > I am unaware of their being any rules on compilation. > Rules are determined by the language standards. I believe that C mandates no reassociation; Fortran allows reassociation unless explicit parentheses are present in the source, but this is not (yet) implemented by GCC. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
