#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):
Looks like an alignment error. Here's the `gdb` trace of the negation in
`showSignedFloat`:
{{{
0x000000010524a8dd in ?? ()
1: x/i $rip 0x10524a8dd: movsd 0x18(%rbx),%xmm0
(gdb)
0x000000010524a8e2 in ?? ()
1: x/i $rip 0x10524a8e2: movsd 0x3070c2(%rip),%xmm7 #
0x1055519ac
(gdb)
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
}
}}}
Note that `%xmm7` is loaded with all zeroes. If we look at the memory
from which `%xmm7` was loaded, we see:
{{{
(gdb) p8 0x1055519ac
0x1055519e4: 0x69666e4900000000
0x1055519dc: 0x7974696e69
0x1055519d4: 0x666e492d00000000
0x1055519cc: 0x4e614e00000000
0x1055519c4: 0x65756c615620
0x1055519bc: 0x646162203a6f5464
0x1055519b4: 0x6e756f7280000000
0x1055519ac: 0x0
(gdb)
}}}
We're off by four bytes. The correct mask starts four bytes higher, at
`0x1055519b0`
(look for `80000000`). This is good --- it explains why in one of my
builds, the error didn't show up. In that case, by chance the memory was
aligned on the correct boundary.
The question now is whether the relocations need to be corrected, or if
the memory images are not being aligned properly when they are copied from
the object file.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4867#comment:45>
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
