#4867: ghci displays negative floats incorrectly (was: Incorrect result from
trig
functions)
-------------------------------+--------------------------------------------
Reporter: gwright | Owner: gwright
Type: bug | Status: new
Priority: high | Milestone: 7.0.2
Component: GHCi | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
-------------------------------+--------------------------------------------
Comment(by gwright):
OK, I've checked whether `%xmm7` is loaded correctly and it is. Using
`gdb` to set a watchpoint on `%xmm7`, I can see the correct mask to invert
a double being loaded:
{{{
(gdb) c
Continuing.
-Watchpoint 2: $xmm7
Old value = {
v4_float = {0, 0, -1.875, 0},
v2_double = {0, -1},
v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, -65, -16, 0, 0, 0, 0, 0, 0},
v8_int16 = {0, 0, 0, 0, -16400, 0, 0, 0},
v4_int32 = {0, 0, -1074790400, 0},
v2_int64 = {0, -4616189618054758400},
uint128 = 61631
}
New value = {
v4_float = {0, 0, 0, 0},
v2_double = {0, 0},
v16_int8 = {0 <repeats 16 times>},
v8_int16 = {0, 0, 0, 0, 0, 0, 0, 0},
v4_int32 = {0, 0, 0, 0},
v2_int64 = {0, 0},
uint128 = 0
}
0x000000010524a8ea in ?? ()
(gdb) c
Continuing.
-Watchpoint 2: $xmm7
Old value = {
v4_float = {0, 0, 0, 0},
v2_double = {0, 0},
v16_int8 = {0 <repeats 16 times>},
v8_int16 = {0, 0, 0, 0, 0, 0, 0, 0},
v4_int32 = {0, 0, 0, 0},
v2_int64 = {0, 0},
uint128 = 0
}
New value = {
v4_float = {0, 0, -0, 0},
v2_double = {0, -0},
v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, -128, 0, 0, 0, 0, 0, 0, 0},
v8_int16 = {0, 0, 0, 0, -32768, 0, 0, 0},
v4_int32 = {0, 0, -2147483648, 0},
v2_int64 = {0, -9223372036854775808},
uint128 = 128
}
}}}
Look at `v_int64`, the nonzero part is the representation of the IEEE 754
sign bit mask. To see it in hex,
{{{
(gdb) info reg all
<snip>
xmm7 {
v4_float = {0, 0, -0, 0},
v2_double = {0, -0},
v16_int8 = {0, 0, 0, 0, 0, 0, 0, 0, -128, 0, 0, 0, 0, 0, 0, 0},
v8_int16 = {0, 0, 0, 0, -32768, 0, 0, 0},
v4_int32 = {0, 0, -2147483648, 0},
v2_int64 = {0, -9223372036854775808},
uint128 = 128
} (raw 0x00000000000000800000000000000000)
<snip>
}}}
The `raw` value has hex 8 followed by 15 zeros in the lower half, which
the sign bit mask.
I think this is telling us that one relocation bug has been fixed, but
there is probably still another. Not surprising, given the untested and
rickety nature of the original code. The only question is whether to
close out this ticket and open a new one, or continue working on this
under this ticket.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4867#comment:34>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
