On 15 March 2013 18:35, Johannes Pfau <[email protected]> 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';
