Floating point constant folding bug?

[Iain Buclaw]

On 15 March 2013 18:35, Johannes Pfau <nospam at example.com> wrote:

> Forget what I've said, I somehow read that code as a bitwise/reinterpret
> cast but of course the code does an integer/float conversion so it's
> probably OK.
>
> This is more interesting:
>
> ---
>     float f = float.infinity;
>     float f2 = float.max;
>     int i = cast(int) f;
>     int i2 = cast(int) f2;
>     writefln("0x%x == int.min(0x%x)", i, int.min);
>     writefln("0x%x == int.max(0x%x)", cast(int)float.infinity, int.max);
>     writefln("0x%x == int.min(0x%x)", i2, int.min);
>     writefln("0x%x == int.max(0x%x)", cast(int)float.max, int.max);
> ---
>
> const folding expands to int.max, but the same code at runtime expands
> to int.min. C does not define what happens if too large float values
> are cast into ints. Do you know if D somehow defines this?
>
> (There's a failing test in the test suite which assumes that the result
> is int.min in all cases above)
>


I think the behaviour from DMD is more incidental than intended.  They use
C's FLOAT_INFINITY, etc, macros. But because of the way it's written, gcc
doesn't optimise the use of the value.   Whereas with gdc, because it uses
gcc's real_t types, values of extreme numbers may change to be either
2147483647 or -2147483648 depending on whether -O is used.  As I said, in
most cases you can see the same behaviour in C.

I can see if there might be some flag I can set to try and make gcc's
codegen more safe for floats, but that might have impact on runtime.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130315/e9c88ad2/attachment.html>