Re: [GHC] #5737: Template Haskell can't derive Read, Show, Eq instances
#5737: Template Haskell can't derive Read, Show, Eq instances
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.1
Component: Template Haskell | Version: 7.0.4
Keywords:| Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* difficulty: = Unknown
* milestone: = 7.6.1
Comment:
Thanks for the report.
7.4 and HEAD are giving a different error:
{{{
Ambiguous type variable `t0' in the constraint:
(Show t0)
arising from the 'deriving' clause of a data type declaration
Probable fix: use a 'standalone deriving' declaration instead
When deriving the instance for (Show Alpha)
In the Template Haskell quotation
[d| data Alpha = Alpha $(conT n) deriving (Show, Read) |]
In the expression:
[d| data Alpha = Alpha $(conT n) deriving (Show, Read) |]
Failed, modules loaded: none.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5737#comment:2
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] #5741: openFile should fail if null bytes are in the argument
#5741: openFile should fail if null bytes are in the argument -+-- Reporter: Veinor| Owner: Type: feature request | Status: new Priority: high | Milestone: 7.6.1 Component: libraries/base| Version: 7.2.1 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * priority: normal = high * difficulty: = Unknown * milestone: = 7.6.1 Comment: Should we make this throw an exception, or is checking for NULs just part of the input sanitation that the programmer needs to do? I'm inclined towards the latter (although we should probably document it somewhere if so). What do other people think? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5741#comment:1 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] #5742: compiler option -XDoRec crash
#5742: compiler option -XDoRec crash
---+
Reporter: Huenniger | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler| Version: 7.2.1
Keywords: frisby recusive do -XDoRec | Os: Unknown/Multiple
Architecture: x86 | Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by igloo):
* difficulty: = Unknown
Old description:
I tried to compile a complex 200 KByte grammer using the library frisby.
I got a linking error. The file is essentially one big do rec block and
thus needs -XDoRec compiler option.
I installed the latest GHC Version and use the minus -C flag to analyze
the problem, which resulted in a ghc panic.
dirk@dirk-desktop:~/temp/wb2pdf/trunk/exp$ ghc -C -XDoRec Grammer.hs
addFlag by -C on the commandline:
Warning: The -fvia-C flag does nothing; it will be removed in a
future GHC release
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.2 for i386-unknown-linux):
pipeLoop: at phase As but I wanted to stop at phase HCc
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
New description:
I tried to compile a complex 200 KByte grammer using the library frisby. I
got a linking error. The file is essentially one big do rec block and
thus needs -XDoRec compiler option.
I installed the latest GHC Version and use the minus -C flag to analyze
the problem, which resulted in a ghc panic.
{{{
dirk@dirk-desktop:~/temp/wb2pdf/trunk/exp$ ghc -C -XDoRec Grammer.hs
addFlag by -C on the commandline:
Warning: The -fvia-C flag does nothing; it will be removed in a future
GHC release
ghc: panic! (the 'impossible' happened)
(GHC version 7.2.2 for i386-unknown-linux):
pipeLoop: at phase As but I wanted to stop at phase HCc
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5742#comment:3
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] #5742: compiler option -XDoRec crash
#5742: compiler option -XDoRec crash ---+ Reporter: Huenniger | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.2.1 Keywords: frisby recusive do -XDoRec | Os: Unknown/Multiple Architecture: x86 | Failure: Compile-time crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * milestone: = 7.6.1 Comment: Thanks for the report -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5742#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] #5743: Configurably use system-provided libffi
#5743: Configurably use system-provided libffi -+-- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal| Milestone: 7.6.1 Component: Build System | Version: 7.2.1 Keywords:| Os: Linux Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.6.1 Comment: It would be simpler if we can always do the same thing. Perhaps we should look at whether OS X comes with libffi, and whether there's a bin tarball for mingw. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5743#comment:1 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] #5744: List layouts
#5744: List layouts ---+ Reporter: nsch | Owner: nsch Type: feature request | Status: closed Priority: normal| Milestone: Component: Compiler |Version: 7.2.1 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase:| Blockedby: Blocking:|Related: ---+ Changes (by igloo): * status: new = closed * resolution: = wontfix Comment: I think there are still some open design questions here that would be better worked out on a wiki page, so I'm going to close this ticket for now. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5744#comment:19 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] #5751: code works in 7.0 but hangs in 7.2/7.4 due to changes in type checker (most likely)
#5751: code works in 7.0 but hangs in 7.2/7.4 due to changes in type checker (most likely) ---+ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.1 Component: Compiler| Version: 7.2.1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * milestone: = 7.6.1 Comment: It doesn't sound like the proper fix is feasible for 7.4, so I'll milestone this for 7.6. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5751#comment:9 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
[GHC] #5777: Panic with Arrow Notation and GADTs
#5777: Panic with Arrow Notation and GADTs
+---
Reporter: benmos | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1-rc1 | Keywords: arrows, GADTs
Os: MacOS X | Architecture: x86
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
The following code panics GHC (with 7.0.3, 7.2 and 7.4.0.20111219):
{{{
{-# LANGUAGE Arrows, GADTs #-}
import Control.Arrow
data Value a where BoolVal :: Value Bool
class ArrowInit f where
arrif :: f b - ()
instance ArrowInit Value where
arrif = proc BoolVal - returnA - ()
-- arrif = arr (\BoolVal - ())
}}}
I am attaching the -dcore-lint from 7.4.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5777
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] #5752: loop when using variables in TH splice
#5752: loop when using variables in TH splice
-+--
Reporter: srl | Owner:
Type: bug | Status: new
Priority: normal| Milestone: 7.6.1
Component: Template Haskell | Version: 7.0.3
Keywords:| Os: Linux
Architecture: x86_64 (amd64)| Failure: Compile-time crash
Difficulty: Unknown |Testcase:
Blockedby:|Blocking:
Related:|
-+--
Changes (by igloo):
* difficulty: = Unknown
* milestone: = 7.6.1
Comment:
Thanks for the report.
The code is:
{{{
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Language.Haskell.TH
main = undefined
x = 3
data A = A $( return . (\ts - foldl AppT (TupleT (length ts)) ts) .
replicate x = [t| Double |] )
}}}
HEAD and 7.4 give:
{{{
q.hs:12:80:
GHC internal error: `x' is not in scope during type checking, but it
passed the renamer
tcl_env of environment: [(rfT, AThing *), (rfU, ANothing)]
In the first argument of `replicate', namely `x'
In the second argument of `(.)', namely `replicate x'
In the second argument of `(.)', namely
`(\ ts - foldl AppT (TupleT (length ts)) ts) . replicate x'
}}}
It looks to me like the code is wrong, but we should get a proper error
that `x` can't be used in a splice in the module that defines it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5752#comment:1
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] #5755: cabal install ghc-core fails on Mac Lion on latest Haskell Platform
#5755: cabal install ghc-core fails on Mac Lion on latest Haskell Platform +--- Reporter: George | Owner: Type: bug| Status: closed Priority: normal | Milestone: Component: libraries (other) |Version: 7.0.4 Resolution: invalid| Keywords: gcc preprocess Os: MacOS X| Architecture: x86_64 (amd64) Failure: Other | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by igloo): * status: new = closed * resolution: = invalid Comment: I'm afraid you'll need to mail the maintainer of the package, unless you think the bug is actually in GHC. Note that it looks like it is actually `pcre-light` that is failing to install. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5755#comment:2 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] #5756: Specialize sequence into sequence_ automatically
#5756: Specialize sequence into sequence_ automatically
---+
Reporter: EyalLotem | Owner:
Type: feature request | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.2.1
Resolution: wontfix | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase:| Blockedby:
Blocking:|Related:
---+
Changes (by igloo):
* status: new = closed
* difficulty: = Unknown
* resolution: = wontfix
Comment:
Note that with `-Wall` you get a warning if you ignore a non-`()` result:
{{{
module Q where
f :: IO ()
f = do sequence [putStr A, putStr B]
putStr C
}}}
{{{
$ ghc -c -O q.hs -fforce-recomp -Wall
q.hs:5:8: Warning:
A do-notation statement discarded a result of type [()].
Suppress this warning by saying _ - sequence
[putStr A, putStr B],
}}}
Thanks for the suggestion, but I'm not sure it's worth adding a special
case to the compiler to do the rewrite - especially as it's not a type-
preserving transformation.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5756#comment:1
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] #5777: core lint error with arrow notation and GADTs (was: Panic with Arrow Notation and GADTs)
#5777: core lint error with arrow notation and GADTs
+---
Reporter: benmos | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.4.1-rc1 | Keywords: arrows, GADTs
Os: MacOS X | Architecture: x86
Failure: Compile-time crash | Testcase:
Blockedby: | Blocking:
Related: |
+---
Comment(by ross):
Simplified version, avoiding classes:
{{{
{-# LANGUAGE Arrows, GADTs #-}
module ArrowBug5777 where
import Control.Arrow
data Value a where BoolVal :: Value Bool
arrif :: Value Bool - ()
arrif = proc BoolVal - returnA - ()
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5777#comment:1
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] #5761: Getting stdout and stderr as a single handle from createProcess does not work on Windows
#5761: Getting stdout and stderr as a single handle from createProcess does not work on Windows --+- Reporter: SimonHengel| Owner: Type: bug| Status: new Priority: normal | Milestone: 7.6.1 Component: libraries/process | Version: Keywords: | Os: Windows Architecture: x86| Failure: Incorrect result at runtime Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5761#comment:3 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] #5766: Asynchronous exception bugs in readProcess and readProcessWithExitCode
#5766: Asynchronous exception bugs in readProcess and readProcessWithExitCode --+- Reporter: basvandijk | Owner: Type: bug| Status: patch Priority: normal | Milestone: 7.6.1 Component: libraries/process | Version: 7.2.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown|Testcase: Blockedby: |Blocking: Related: | --+- Changes (by igloo): * status: new = patch * difficulty: = Unknown * milestone: = 7.6.1 Comment: Thanks for the patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5766#comment:1 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] #5767: Integer inefficiencies
#5767: Integer inefficiencies --+- Reporter: rl | Owner: igloo Type: bug | Status: new Priority: highest | Milestone: 7.4.1 Component: Compiler |Version: 7.5 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: --+- Changes (by igloo): * owner: = igloo * priority: normal = highest * milestone: = 7.4.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5767#comment:5 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] #5769: Incorrect error message when compiling with PolyKinds and a type family
#5769: Incorrect error message when compiling with PolyKinds and a type family +--- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler (Type checker) | Version: 7.4.1-rc1 Keywords: PolyKinds| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | +--- Changes (by igloo): * owner: = dreixel * difficulty: = Unknown * priority: normal = high * milestone: = 7.4.1 Comment: Thanks for the report. dreixel, if this is easy to fix we may as well get it into 7.4.1, although it's not actually a regression as PolyKinds is new. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5769#comment:2 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] #5771: Confusing printout with PolyKinds
#5771: Confusing printout with PolyKinds -+-- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.4.1-rc1 Keywords: PolyKinds | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Other Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5771#comment:1 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] #5544: threadDelay with large values crashes the IO manager on 64-bit OS X
#5544: threadDelay with large values crashes the IO manager on 64-bit OS X
---+
Reporter: carlhowells | Owner: tibbe
Type: bug | Status: new
Priority: high| Milestone: 7.4.1
Component: Runtime System | Version: 7.2.1
Keywords: | Os: MacOS X
Architecture: x86_64 (amd64) | Failure: None/Unknown
Difficulty: |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by sanketr):
I can reproduce it consistently using the code below (only on 7.0.3, not
7.4.1 RC1):
{{{
import Control.Concurrent (forkIO, threadDelay)
main = forkIO $ threadDelay maxBound
}}}
{{{
$ ghc t.hs -threaded -rtsopts
$ ./t
t: ioManagerDie: write: Invalid argument
t: kevent: invalid argument (Invalid argument)
$ uname -a
Darwin desktop.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9
20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5544#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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when
compiled
---+
Reporter: lpsmith | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler| Version: 7.4.1-rc1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Changes (by igloo):
* owner: = simonmar
* difficulty: = Unknown
* priority: normal = highest
* milestone: = 7.4.1
Comment:
Thanks for the report.
This is a regression: It works in 7.2 and 7.0.
Simon, do you know what's up?
I skimmed 6b1098511aaabd2c9503ee7be6da1944466f9cb4, and while I don't
think it's relevant, shouldn't the tv_nsec and tv_usec fields in these
hunks have the complete seconds removed?:
{{{
-it.it_value.tv_sec = itimer_interval / 1000;
-it.it_value.tv_nsec = (itimer_interval % 1000) * 100;
+it.it_value.tv_sec = TimeToSeconds(itimer_interval);
+it.it_value.tv_nsec = TimeToNS(itimer_interval);
}}}
{{{
-it.it_value.tv_sec = itimer_interval / 1000;
-it.it_value.tv_usec = (itimer_interval % 1000) * 1000;
+it.it_value.tv_sec = TimeToSeconds(itimer_interval);
+it.it_value.tv_usec = TimeToUS(itimer_interval);
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#comment:3
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] #5740: Remove tabs from parser/LexCore.hs
#5740: Remove tabs from parser/LexCore.hs +--- Reporter: nsch | Owner: nsch Type: bug| Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler (Parser) |Version: 7.2.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Difficulty: Unknown Testcase: | Blockedby: Blocking: |Related: +--- Changes (by igloo): * status: patch = closed * difficulty: = Unknown * resolution: = fixed * milestone: = 7.6.1 Comment: Applied, thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5740#comment:2 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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when
compiled
---+
Reporter: lpsmith | Owner: simonmar
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler| Version: 7.4.1-rc1
Keywords: | Os: Linux
Architecture: x86_64 (amd64) | Failure: Runtime performance bug
Difficulty: Unknown |Testcase:
Blockedby: |Blocking:
Related: |
---+
Comment(by lpsmith):
Ok, I was mistaken. The program I though I compiled with ghc-7.4.1-rc1 I
actually compiled with ghc-7.0.3, and so the program I used to test
{{{threadWaitRead}}} also saturates the CPU. Although it may not be of
any great interest to the bug-hunters, I'll attach the program, it's a
straightforward port of a sample program from the PostgreSQL source
distribution to the http://hackage.haskell.org/package/postgresql-libpq
bindings.
So it seems to be a problem with blocking IO in general. I find it
curious that none of my test programs exhibit this problem when run inside
GHCi.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled ---+ Reporter: lpsmith | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.4.1 Component: Compiler| Version: 7.4.1-rc1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by igloo): GHCi is linked with `-threaded` by default, which uses a different implementation of this stuff. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#comment:5 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] #5767: Integer inefficiencies
#5767: Integer inefficiencies
--+-
Reporter: rl | Owner: igloo
Type: bug | Status: new
Priority: highest | Milestone: 7.4.1
Component: Compiler |Version: 7.5
Resolution: | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
--+-
Comment(by rl):
I finally found a small test case for the missing
`integerToInt/smallInteger` rule:
{{{
foo :: (Integral a, Num a) = a - a
{-# INLINE foo #-}
foo x = fromIntegral x
bar :: Int - Int
bar x = foo x
}}}
The head generates this:
{{{
foo_$sfoo =
\ (eta_B1 :: Int) -
case eta_B1 of _ { I# i_ara -
case integerToInt (smallInteger i_ara) of wild1_ard { __DEFAULT -
I# wild1_ard
}
}
bar = foo_$sfoo
}}}
Whereas 7.2.2 generates this:
{{{
bar_$sfoo = \ (eta_B1 :: Int) - eta_B1
bar = bar_$sfoo
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5767#comment:6
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] #5775: Inconsistency in demand analysis
#5775: Inconsistency in demand analysis -+-- Reporter: rl| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.6.1 Component: Compiler | Version: 7.5 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.6.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5775#comment:2 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] #5775: Inconsistency in demand analysis
#5775: Inconsistency in demand analysis -+-- Reporter: rl| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.4.2 Component: Compiler | Version: 7.5 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * milestone: 7.6.1 = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5775#comment:3 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] #5776: Rule matching regression
#5776: Rule matching regression -+-- Reporter: rl| Owner: Type: bug | Status: new Priority: normal| Milestone: 7.4.2 Component: Compiler | Version: 7.5 Keywords:| Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby:|Blocking: Related:| -+-- Changes (by igloo): * difficulty: = Unknown * milestone: = 7.4.2 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5776#comment:1 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] #5723: GHCi (7.4.0.20111219) sometimes segfaults when reading .ghci
#5723: GHCi (7.4.0.20111219) sometimes segfaults when reading .ghci ---+ Reporter: konn| Owner: simonmar Type: bug | Status: new Priority: high| Milestone: 7.4.1 Component: GHCi| Version: 7.3 Keywords: GHCi, SEGV | Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * priority: highest = high Comment: The plan is to just document the installer as requiring OS X = 10.7 and XCode = 4.1. Ideally we'd also have the installer warn if it finds it is being used on an older version. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5723#comment:7 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
[GHC] #5778: GHCi won't load compiled object files outside of a package
#5778: GHCi won't load compiled object files outside of a package
--+-
Reporter: lpsmith | Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 7.4.1-rc1 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: None/Unknown | Testcase:
Blockedby:| Blocking:
Related:|
--+-
{{{
$ ghci fib.hs
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Fib ( fib.hs, interpreted )
Ok, modules loaded: Fib.
fib 26
121393
(0.23 secs, 69689600 bytes)
:q
Leaving GHCi.
$ ghc fib.hs
[1 of 1] Compiling Fib ( fib.hs, fib.o )
$ ghci fib.hs
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Ok, modules loaded: Fib.
fib 26
121393
(0.04 secs, 37823328 bytes)
}}}
{{{
$ ghci fib.hs
GHCi, version 7.4.0.20120111: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Fib ( fib.hs, interpreted )
Ok, modules loaded: Fib.
fib 26
121393
(0.25 secs, 71126112 bytes)
:q
Leaving GHCi.
$ ghc fib.hs
[1 of 1] Compiling Fib ( fib.hs, fib.o )
$ ghci fib.hs
GHCi, version 7.4.0.20120111: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Fib ( fib.hs, interpreted )
Ok, modules loaded: Fib.
fib 26
121393
(0.24 secs, 69966016 bytes)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5778
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] #5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when compiled ---+ Reporter: lpsmith | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.4.1 Component: Compiler| Version: 7.4.1-rc1 Keywords: | Os: Linux Architecture: x86_64 (amd64) | Failure: Runtime performance bug Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Comment(by lpsmith): Oh, right, I didn't notice that the program I was writing when I ran into this bug wasn't not being linked -threaded. And this problem does go away when I do that. Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5773#comment:6 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
[GHC] #5779: SPECIALISE pragma generates wrong activations
#5779: SPECIALISE pragma generates wrong activations
-+--
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.5 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: Runtime performance bug | Testcase:
Blockedby: | Blocking:
Related: |
-+--
It seems that in the current HEAD, the `SPECIALISE` pragma generates a
rule with the same activation as the function that is being specialised
which is utterly wrong. A small example:
{{{
foo :: Num a = a - a
{-# NOINLINE foo #-}
foo x = x+1
{-# SPECIALISE foo :: Int - Int #-}
}}}
The HEAD generates this rule which never fires:
{{{
SPEC T.foo [NEVER] forall $dNum :: GHC.Num.Num GHC.Types.Int
T.foo @ GHC.Types.Int $dNum = T.foo_foo
}}}
If I change the `NOINLINE` pragma to `INLINE [0]`, the rule will get the
activation `[0]`. 7.2.2 behaves as expected:
{{{
SPEC T.foo [ALWAYS] forall $dNum :: GHC.Num.Num GHC.Types.Int
T.foo @ GHC.Types.Int $dNum = T.foo_foo
}}}
I haven't checked 7.4 but if this happens there, too, then fixing it
before the release would be great. I assume it's just a typo somewhere.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5779
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
