Re: [GHC] #2722: loop when compiling with -O option with ghc-6.10.0.20081019
#2722: loop when compiling with -O option with ghc-6.10.0.20081019 -+-- Reporter: uwe | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.0.3 Component: libraries (other) |Version: 7.0.1 Resolution: | Keywords: arrows Testcase: tyepcheck/should_run/T2722 | Blockedby: Difficulty: Unknown | Os: Linux Blocking: | Architecture: x86_64 (amd64) Failure: Runtime crash | -+-- Comment(by litoh): I really tried to help but after 6 hrs of unsuccessfully compiling ghc- HEAD-2011-01-10-ghc.tar.bz2 on Ubuntu x64 Linux I gave up. Sorry. Maybe there is a better place to discuss this but I get the following error when doing $ ghc/make Configuring haddock-2.8.0... make[1]: *** No rule to make target `libraries/dph/ghc.mk'. Stop. make: *** [all] Error 2 Another problem appears to be that darcs is constantly freezing $ ./darcs-all get Copying pristine 486 done, 6 queued. legacy $ darcs -v 2.4.4 (release) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2722#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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):
The real mystery here is why compiled code shows only a single minus sign,
but ghci shows two.
A look at the code in `Float.lhs` shows that two minus signs ought to be
displayed. Start with the instance for `Show Double`:
{{{
instance Show Double where
showsPrec p = showSignedFloat showFloat p
}}}
(In the above, I've change the `x` in the original source to `p`, since
the argument is the `Int` precedence, not the `Double` value to be
displayed.)
The definitions of `showSignedFloat` and `showFloat` are
{{{
showSignedFloat :: (RealFloat a)
= (a - ShowS) -- ^ a function that can show unsigned values
- Int-- ^ the precedence of the enclosing context
- a -- ^ the value to show
- ShowS
showSignedFloat showPos p x
| x 0 || isNegativeZero x
= showParen (p 6) (showChar '?' . showPos (-x))
| otherwise = showPos x
-- | Show a signed 'RealFloat' value to full precision
-- using standard decimal notation for arguments whose absolute value lies
-- between @0.1@ and @9,999,999@, and scientific notation otherwise.
showFloat :: (RealFloat a) = a - ShowS
showFloat x = showString (formatRealFloat FFGeneric Nothing x)
}}}
The last thing we need is the first bit of `formatRealFloat`:
{{{
formatRealFloat :: (RealFloat a) = FFFormat - Maybe Int - a - String
formatRealFloat fmt decs x
| isNaN x = NaN
| isInfinite x = if x 0 then -Infinity else Infinity
| x 0 || isNegativeZero x = '!' : doFmt fmt (floatToDigits (toInteger
base) (-x))
| otherwise = doFmt fmt (floatToDigits (toInteger base)
x)
where
snip
}}}
Also in the above I have subsituted '!' and '?' for the '-' signs. This
will let us see which path through the code is taken.
Now say we want to show a `Double`. When `ghci` displays a `Double`, say
`-1.0`, the `Show` instance should be invoked as
{{{
showsPrec 0 (-1.0)
}}}
Expand this out:
{{{
showSignedFloat showFloat 0 (-1.0)
}}}
`showSignedFloat` sees that the argument is negative, so it prefixes a '?'
to the output string. `showFloat` also sees a negative argument, so it
prefixes a '!' to the output string. Normal order evaluation is from the
outside in, so we should see '?!' before the numeric value. Let's check:
{{{
Prelude GHC.Float showsPrec 0 (-1.0)
?!1.0
}}}
So it appears that `ghci` is doing exactly what is specified by the code
in `Float.lhs`.
Here's the real mystery. Let's compile this program, which should produce
the same output:
{{{
gwright-macbook cat foo.hs
--
-- Test returning -1.0
--
module Main where
main = putStrLn (show (-1.0))
}}}
Compiling and running,
{{{
gwright-macbook inplace/bin/ghc-stage2 --make foo.hs
[1 of 1] Compiling Main ( foo.hs, foo.o )
Linking foo ...
ld: warning: -read_only_relocs cannot be used with x86_64
gwright-macbook ./foo
?1.0
}}}
So we have used `showSignedFloat` but what happened to `formatRealFloat`?
Did it get passed an incorrect (positive) argument? Or is the compiler
doing some kind of optimization that changes the code?
It seems as if `Float.lhs` needs to be corrected so it only displays a
single '-' sign, but whatever is happening needs to be understood before
we make changes, so we don't simply cover up the real bug.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:38
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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 batterseapower): I think a single minus sign is the expected result, and it is what I get with GHC and GHCi (near HEAD) on OS X 10.6. Note that: showSignedFloat showFloat 0 (-1.0) Calls showFloat with the last argument '''negated''' after outputting a minus sign, so showFloat itself will not get a chance to produce an extra minus sign. (The relevant line of showSignedFloat is Float.lhs:1016) The question seems to be why that negation is not happening on your machine. This seems unlikely, but is it possible that your GHCi is still somehow finding the version of the libraries that you edited before, and that version accidentally removed the negation? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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 altaic): It's happening on both of our machines, and I did a fresh pull from HEAD. What optimizations did you use for the build without the bug? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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 batterseapower): I should clarify that I'm doing a 32 bit build of GHC, so my failure to reproduce the problems is expected. However, I'm trying to point out the problem does not seem to be with the code in Float.hs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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 altaic):
Agreed. I'm going to have another look at `Linker.c`.
Optimizations appear to effect the bug quite a bit. The double '-'
happened for me with the devel2 BuildFlavour. With quickest
BuildFlavour (no optimizations) I get the following output from GHCi:
{{{
Prelude -1.0 :: Float
-1.0
Prelude -1.0 :: Double
1.0253
Prelude (-1.0 :: Double) + (1.0 :: Double)
2.0253
}}}
So it's not just the failed negation of `x` in `showSignedFloat`; it seems
that other negations are failing as well, which is unsurprising.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:42
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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): Replying to [comment:39 batterseapower]: I think a single minus sign is the expected result, and it is what I get with GHC and GHCi (near HEAD) on OS X 10.6. Note that: showSignedFloat showFloat 0 (-1.0) Calls showFloat with the last argument '''negated''' after outputting a minus sign, so showFloat itself will not get a chance to produce an extra minus sign. (The relevant line of showSignedFloat is Float.lhs:1016) The question seems to be why that negation is not happening on your machine. Checking again (after coffee) I agree with this. My above argument is wrong. The question is why the negation is not being done. `showFloat` ought to see a positive argument. This seems unlikely, but is it possible that your GHCi is still somehow finding the version of the libraries that you edited before, and that version accidentally removed the negation? No, I can edit the libraries, change the minus signs to other characters, and when I rebuild I see the expected result (i.e., the minus signs are changed to the specified characters). Thinking about this some more, there are probably more incorrect relocations. `Doubles` are negated by `xor`-ing them with a fixed bitmask, `0x8000`. The thing to do is to track down the assembly code corresponding to the negation in `showSignedFloat`. One thing that would cause this problem is if the loaded bitmask were all zeroes instead of having '1' in the msb. `xor`-ing with an all zero mask will return the `Double` value unchanged. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:43 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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):
Replying to [comment:42 altaic]:
Agreed. I'm going to have another look at `Linker.c`.
Optimizations appear to effect the bug quite a bit. The double '-'
happened for me with the devel2 BuildFlavour. With quickest
BuildFlavour (no optimizations) I get the following output from GHCi:
{{{
Prelude -1.0 :: Float
-1.0
Prelude -1.0 :: Double
1.0253
Prelude (-1.0 :: Double) + (1.0 :: Double)
2.0253
}}}
So it's not just the failed negation of `x` in `showSignedFloat`; it
seems that other negations are failing as well, which is unsurprising.
Changes with optimization level point to a relocation issue. As the code
changes, the references to constant data move around, and the relocations
are different.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:44
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)
#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`:
{{{
0x00010524a8dd in ?? ()
1: x/i $rip 0x10524a8dd: movsd 0x18(%rbx),%xmm0
(gdb)
0x00010524a8e2 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:0x69666e49
0x1055519dc:0x7974696e69
0x1055519d4:0x666e492d
0x1055519cc:0x4e614e
0x1055519c4:0x65756c615620
0x1055519bc:0x646162203a6f5464
0x1055519b4:0x6e756f728000
0x1055519ac:0x0
(gdb)
}}}
We're off by four bytes. The correct mask starts four bytes higher, at
`0x1055519b0`
(look for `8000`). 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
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4838: LLVM mangler takes too long at runtime
#4838: LLVM mangler takes too long at runtime -+-- Reporter: benl |Owner: dterei Type: bug | Status: merge Priority: normal|Milestone: 7.2.1 Component: Compiler (LLVM) | Version: 7.0.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: MacOS X | Blocking: Architecture: Unknown/Multiple | Failure: Compile-time performance bug -+-- Changes (by dterei): * status: new = merge Comment: Fixed! Thanks for the bug report, old code was embarrassingly bad. The dph example you used now compiles in a little under 3 minutes. The mangler now only takes about 2 seconds to do its job in this case so extra time is all due to llvm. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4838#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4209: LLVM: Vector code segfaults under OSX
#4209: LLVM: Vector code segfaults under OSX ---+ Reporter: dterei |Owner: dterei Type: bug | Status: merge Priority: normal |Milestone: 7.0.2 Component: Compiler (LLVM) | Version: 6.13 Keywords: osx tntc llvm segfault | Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86 | Failure: Runtime crash ---+ Changes (by dterei): * status: new = merge Comment: New mangler has solved this issue as well! OSX is working well these days. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4209#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
