[Bug middle-end/47990] Missed promotion of double precision constants to single precision for -funsafe-math-optimizations

[joseph at codesourcery dot com]

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).