This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

# Re: Patch gcc-4.0 should not apply mathematical associative rulesfor addition or multiplication

*From*: Roger Sayle <roger at eyesopen dot com>
*To*: Dale Johannesen <dalej at apple dot com>, Geoff Keating <geoffk at geoffk dot org>, Fariborz Jahanian <fjahanian at apple dot com>, Ziemowit Laski <zlaski at apple dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
*Date*: Thu, 7 Oct 2004 20:58:00 -0600 (MDT)
*Subject*: Re: Patch gcc-4.0 should not apply mathematical associative rulesfor addition or multiplication

On Thu, 7 Oct 2004, Roger Sayle wrote:
> My feeling is that unless someone feels its worth going to effort of
> implementing Dale's checks explicitly for multiplications by powers of
> two with either both positive or both negative exponents, that we should
> do what we've always done for floating point reassociation and guard it
> with flag_unsafe_math_optimizations.
Thinking more about the necessary and sufficient conditions for
converting (x * C1) * C2 into x * (C1 * C2), I believe that it
is sufficent that the signs of the IEEE exponents match, and either
C1 or C2 is a power of two.
To counter one of RTH's recent suggestions that HONOR_INFINITIES
should be used instead of flag_unsafe_math_optimizations, it's easy
to show that swapping co-efficients (x * C1) * C2 where C1 = O.5,
C2 = 2.0 and x is epsilon, produces the same "exponent truncation"
but with underflow rather than overflow. i.e. this isn't a infinity
specific restriction.
It should also be pointed out that with -fsignaling-nans, (x * C1) * C2
raises more floating point exceptions that x * (C1*C2), so reassociation
also has to be disallowed when flag_signaling_nans.
Once again, flag_unsafe_math_optimizations is the way its been done
in the past, and potentially the easiest way to fix the current
regressions.
Roger
--