http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47990
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot
com> 2011-03-04 15:42:39 UTC ---
On Fri, 4 Mar 2011, rguenth at gcc dot gnu.org wrote:
> In 482.sphinx3 we have code like
>
> float foo (float x, float y)
> {
> return ((int)(x/y + 0.5)) * y;
> }
>
> where the addition of 0.5 is performed in double precision. With
> -funsafe-math-optimizations we can demote 0.5 to single precision
> (its exactly representable) also because the result of the addition
> does not take part of further floating point computation but is
> immediately converted to int.
>
> The unsafe part of this optimization occurs when x/y is FLT_MAX
> and we'd truncate to a 64bit integer type. For 32bit integers
> it would probably be safe to do this optimization unconditionally.
No, that's not safe unconditionally; consider x/y == 0x800001p0f, for
example (so adding 0.5f and converting to float results in rounding up to
the next integer in the default round-to-nearest mode, whereas conversion
from floating point to integer in C always rounds towards zero).
