- ghc-tickets - Haskell.org

Re: [GHC] #3064: Very long compile times with type functions
by GHC 06 Nov '14

06 Nov '14

#3064: Very long compile times with type functions -------------------------------------------------+------------------------- Reporter: simonpj | Owner: Type: bug | Status: Priority: low | closed Component: Compiler (Type checker) | Milestone: 7.6.1 Resolution: fixed | Version: Operating System: Unknown/Multiple | 6.10.1 Type of failure: Compile-time performance bug | Keywords: Test Case: perf/compiler/T3064 | Architecture: Blocking: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"096b7e664351d102cc9e15f3aa226a976af5dae2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="096b7e664351d102cc9e15f3aa226a976af5dae2" Switch off lazy flattening (fix Trac #3064) See Note [Lazy flattening] in TcFlatten. Lazy flattening was an apparently good idea which actually made the type inference engine go a LOTS slower in T3064. So I switched it off again. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9774: Type error messages containing calls to assert could be prettier.
by GHC 06 Nov '14

06 Nov '14

#9774: Type error messages containing calls to assert could be prettier. -------------------------------------+------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following piece of code contains a type error. It also contains a call to `assert`. {{{#!hs import Control.Exception.Assert main = putStrLn (assert True 'a') }}} GHC 7.8.3 reports the type error as follows: {{{ Err.hs:3:30: Couldn't match type ‘Char’ with ‘[Char]’ Expected type: String Actual type: Char In the third argument of ‘GHC.IO.Exception.assertError’, namely ‘'a'’ In the first argument of ‘putStrLn’, namely ‘(GHC.IO.Exception.assertError "Err.hs:3:18-23"## True 'a')’ In the expression: putStrLn (GHC.IO.Exception.assertError "Err.hs:3:18-23"## True 'a') }}} The calls to `assert` has already been desugared, which is not necessarily very readable. I think it would be better if GHC just printed the call to `assert` as it appeared in the source. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9358: Improve flag description in the user guide
by GHC 06 Nov '14

06 Nov '14

#9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Sections 4.20 (Flag reference) and 4.10.2 (-f*: platform-independent flags) of the User Guide could use some updating: - `-floopification` is mentioned in 4.20 but not in 4.10.2 (which, sadly, is my fault), - Section 4.10.2 says: "These flags turn on and off individual optimisations. They are normally set via the -O options (...) The flags below are off by default, except where noted below." Does the last sentence mean they are on by default for `-O` or that they are enabled even with `-O0` (which is the default optimisation level)? - What is the default value of `-fmax-simplifier-iterations`? - 4.20 mentions `-fmax-simplifier-iterations`, `-fmax-relevant-bindings` and `-fmax-worker-args` but only the first one is described in 4.10.2 I suspect there are more inconsistencies. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9358> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen
by GHC 06 Nov '14

06 Nov '14

#7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:17 simonmar]: > The comment is wrong, I'll fix it. Please don't. I'll fix it. I'm just working on that code in DynFlags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7192#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen
by GHC 06 Nov '14

06 Nov '14

#7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): @jstolarek we don't want to turn it on by default due to #7679. The comment is wrong, I'll fix it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7192#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9741: Interpreter stack checks are not quite right
by GHC 06 Nov '14

06 Nov '14

#9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In my experimental branch, I'm getting this failure on `tests/ghci/should_run/ghcirun002`: {{{ <interactive>: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 778 (GHC version 7.9.20141029 for x86_64_unknown_linux) }}} The ASSERTION failure means that I must have `-DDEBUG` in my RTS; I have no idea why. My `validate.mk` looks like this: {{{ GhcStage1HcOpts += -ticky -DDEBUG GhcStage2HcOpts += -ticky GhcLibHcOpts += -Wwarn -ticky SplitObjs = YES }}} That is mysterious but not the main point. Somehow we are getting a stack overflow in the interpreter. So I added this line to `Interpreter` on line 772: {{{ debugBelch ( "Interpreter Sp=%p SpLim=%p headroom = %ld\n\n", Sp, SpLim, Sp-SpLim ) ; }}} Sure enough, when running test `ghcirun002` on HEAD, I get this output {{{ Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0238 SpLim=0x7f42649d00c0 headroom = 47 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0210 SpLim=0x7f42649d00c0 headroom = 42 Interpreter Sp=0x7f4264b40230 SpLim=0x7f4264b400c0 headroom = 46 Interpreter Sp=0x7f42649e1230 SpLim=0x7f42649e10c0 headroom = 46 Interpreter Sp=0x7f42649d9230 SpLim=0x7f42649d90c0 headroom = 46 Interpreter Sp=0x7f4264182230 SpLim=0x7f42641820c0 headroom = 46 Interpreter Sp=0x7f426417a230 SpLim=0x7f426417a0c0 headroom = 46 Interpreter Sp=0x7f4264172230 SpLim=0x7f42641720c0 headroom = 46 Interpreter Sp=0x7f426416a230 SpLim=0x7f426416a0c0 headroom = 46 Interpreter Sp=0x7f4264162230 SpLim=0x7f42641620c0 headroom = 46 Interpreter Sp=0x7f426415a230 SpLim=0x7f426415a0c0 headroom = 46 Interpreter Sp=0x7f4264152230 SpLim=0x7f42641520c0 headroom = 46 Interpreter Sp=0x7f426414a230 SpLim=0x7f426414a0c0 headroom = 46 Interpreter Sp=0x7f4264142230 SpLim=0x7f42641420c0 headroom = 46 Interpreter Sp=0x7f426413a230 SpLim=0x7f426413a0c0 headroom = 46 Interpreter Sp=0x7f4264132230 SpLim=0x7f42641320c0 headroom = 46 Interpreter Sp=0x7f42649d0238 SpLim=0x7f42649d00c0 headroom = 47 Interpreter Sp=0x7f4264a1e238 SpLim=0x7f4264a1e0c0 headroom = 47 Interpreter Sp=0x7f4264a16238 SpLim=0x7f4264a160c0 headroom = 47 Interpreter Sp=0x7f4264a0e238 SpLim=0x7f4264a0e0c0 headroom = 47 Interpreter Sp=0x7f4264a06238 SpLim=0x7f4264a060c0 headroom = 47 Interpreter Sp=0x7f4257ff8238 SpLim=0x7f4257ff80c0 headroom = 47 Interpreter Sp=0x7f4257ff0238 SpLim=0x7f4257ff00c0 headroom = 47 Interpreter Sp=0x7f4257fe8238 SpLim=0x7f4257fe80c0 headroom = 47 Interpreter Sp=0x7f4257fe0238 SpLim=0x7f4257fe00c0 headroom = 47 Interpreter Sp=0x7f4257fd8238 SpLim=0x7f4257fd80c0 headroom = 47 Interpreter Sp=0x7f4257fd0238 SpLim=0x7f4257fd00c0 headroom = 47 Interpreter Sp=0x7f4257fc8238 SpLim=0x7f4257fc80c0 headroom = 47 Interpreter Sp=0x7f4257fc0238 SpLim=0x7f4257fc00c0 headroom = 47 Interpreter Sp=0x7f4257fb8238 SpLim=0x7f4257fb80c0 headroom = 47 Interpreter Sp=0x7f4257fb0238 SpLim=0x7f4257fb00c0 headroom = 47 Interpreter Sp=0x7f42641f8238 SpLim=0x7f42641f80c0 headroom = 47 Interpreter Sp=0x7f42641f0238 SpLim=0x7f42641f00c0 headroom = 47 Interpreter Sp=0x7f42644f8238 SpLim=0x7f42644f80c0 headroom = 47 Interpreter Sp=0x7f42644ef238 SpLim=0x7f42644ef0c0 headroom = 47 Interpreter Sp=0x7f42644e7238 SpLim=0x7f42644e70c0 headroom = 47 Interpreter Sp=0x7f42644de238 SpLim=0x7f42644de0c0 headroom = 47 Interpreter Sp=0x7f42644d6238 SpLim=0x7f42644d60c0 headroom = 47 Interpreter Sp=0x7f42644ce238 SpLim=0x7f42644ce0c0 headroom = 47 Interpreter Sp=0x7f42644c5238 SpLim=0x7f42644c50c0 headroom = 47 Interpreter Sp=0x7f42644bd238 SpLim=0x7f42644bd0c0 headroom = 47 Interpreter Sp=0x7f42644b4238 SpLim=0x7f42644b40c0 headroom = 47 Interpreter Sp=0x7f42644ac238 SpLim=0x7f42644ac0c0 headroom = 47 Interpreter Sp=0x7f42644a4238 SpLim=0x7f42644a40c0 headroom = 47 Interpreter Sp=0x7f426449b238 SpLim=0x7f426449b0c0 headroom = 47 Interpreter Sp=0x7f4264493238 SpLim=0x7f42644930c0 headroom = 47 Interpreter Sp=0x7f426448a238 SpLim=0x7f426448a0c0 headroom = 47 Interpreter Sp=0x7f4264482238 SpLim=0x7f42644820c0 headroom = 47 Interpreter Sp=0x7f426447a238 SpLim=0x7f426447a0c0 headroom = 47 Interpreter Sp=0x7f426454e238 SpLim=0x7f426454e0c0 headroom = 47 Interpreter Sp=0x7f42641e8238 SpLim=0x7f42641e80c0 headroom = 47 Interpreter Sp=0x7f426417c238 SpLim=0x7f426417c0c0 headroom = 47 Interpreter Sp=0x7f4264174238 SpLim=0x7f42641740c0 headroom = 47 Interpreter Sp=0x7f426416c238 SpLim=0x7f426416c0c0 headroom = 47 Interpreter Sp=0x7f4264164238 SpLim=0x7f42641640c0 headroom = 47 Interpreter Sp=0x7f426415c238 SpLim=0x7f426415c0c0 headroom = 47 Interpreter Sp=0x7f4264154238 SpLim=0x7f42641540c0 headroom = 47 Interpreter Sp=0x7f426414c238 SpLim=0x7f426414c0c0 headroom = 47 Interpreter Sp=0x7f42643e0238 SpLim=0x7f42643e00c0 headroom = 47 Interpreter Sp=0x7f42643d8238 SpLim=0x7f42643d80c0 headroom = 47 Interpreter Sp=0x7f42643d0238 SpLim=0x7f42643d00c0 headroom = 47 Interpreter Sp=0x7f42643c8238 SpLim=0x7f42643c80c0 headroom = 47 Interpreter Sp=0x7f42643c0238 SpLim=0x7f42643c00c0 headroom = 47 Interpreter Sp=0x7f42643b8238 SpLim=0x7f42643b80c0 headroom = 47 Interpreter Sp=0x7f42643e0238 SpLim=0x7f42643e00c0 headroom = 47 Interpreter Sp=0x7f4264154138 SpLim=0x7f42641540c0 headroom = 15 Interpreter Sp=0x7f42641541d0 SpLim=0x7f42641540c0 headroom = 34 Interpreter Sp=0x7f426415c230 SpLim=0x7f426415c0c0 headroom = 46 Interpreter Sp=0x7f4264164130 SpLim=0x7f42641640c0 headroom = 14 Interpreter Sp=0x7f42641641c8 SpLim=0x7f42641640c0 headroom = 33 Interpreter Sp=0x7f426447a0e0 SpLim=0x7f426447a0c0 headroom = 4 Interpreter Sp=0x7f426447a178 SpLim=0x7f426447a0c0 headroom = 23 Interpreter Sp=0x7f426447a210 SpLim=0x7f426447a0c0 headroom = 42 Interpreter Sp=0x7f4264482138 SpLim=0x7f42644820c0 headroom = 15 Interpreter Sp=0x7f42644821d0 SpLim=0x7f42644820c0 headroom = 34 Interpreter Sp=0x7f426448a228 SpLim=0x7f426448a0c0 headroom = 45 Interpreter Sp=0x7f4264493238 SpLim=0x7f42644930c0 headroom = 47 Interpreter Sp=0x7f426449b130 SpLim=0x7f426449b0c0 headroom = 14 Interpreter Sp=0x7f426449b1c8 SpLim=0x7f426449b0c0 headroom = 33 Interpreter Sp=0x7f42644ac0d0 SpLim=0x7f42644ac0c0 headroom = 2 Interpreter Sp=0x7f42644ac168 SpLim=0x7f42644ac0c0 headroom = 21 Interpreter Sp=0x7f42644ac200 SpLim=0x7f42644ac0c0 headroom = 40 Interpreter Sp=0x7f42644b4230 SpLim=0x7f42644b40c0 headroom = 46 Interpreter Sp=0x7f42644bd108 SpLim=0x7f42644bd0c0 headroom = 9 Interpreter Sp=0x7f42644bd1a0 SpLim=0x7f42644bd0c0 headroom = 28 Interpreter Sp=0x7f42644bd238 SpLim=0x7f42644bd0c0 headroom = 47 Interpreter Sp=0x7f42644ce140 SpLim=0x7f42644ce0c0 headroom = 16 Interpreter Sp=0x7f42644ce1d8 SpLim=0x7f42644ce0c0 headroom = 35 Interpreter Sp=0x7f42644d6218 SpLim=0x7f42644d60c0 headroom = 43 Interpreter Sp=0x7f42644de0e0 SpLim=0x7f42644de0c0 headroom = 4 Interpreter Sp=0x7f42644de178 SpLim=0x7f42644de0c0 headroom = 23 Interpreter Sp=0x7f42644de210 SpLim=0x7f42644de0c0 headroom = 42 Interpreter Sp=0x7f42644e70c0 SpLim=0x7f42644e70c0 headroom = 0 Interpreter Sp=0x7f42644e7158 SpLim=0x7f42644e70c0 headroom = 19 Interpreter Sp=0x7f42644e71f0 SpLim=0x7f42644e70c0 headroom = 38 Interpreter Sp=0x7f42644ef230 SpLim=0x7f42644ef0c0 headroom = 46 Interpreter Sp=0x7f42644f8190 SpLim=0x7f42644f80c0 headroom = 26 Interpreter Sp=0x7f42644f8228 SpLim=0x7f42644f80c0 headroom = 45 Interpreter Sp=0x7f42641f00d8 SpLim=0x7f42641f00c0 headroom = 3 Interpreter Sp=0x7f42641f0170 SpLim=0x7f42641f00c0 headroom = 22 Interpreter Sp=0x7f42641f0208 SpLim=0x7f42641f00c0 headroom = 41 Interpreter Sp=0x7f4257fb8210 SpLim=0x7f4257fb80c0 headroom = 42 Interpreter Sp=0x7f4257fb80f0 SpLim=0x7f4257fb80c0 headroom = 6 Interpreter Sp=0x7f4257fb8188 SpLim=0x7f4257fb80c0 headroom = 25 Interpreter Sp=0x7f4257fb8220 SpLim=0x7f4257fb80c0 headroom = 44 Interpreter Sp=0x7f4257fc00d0 SpLim=0x7f4257fc00c0 headroom = 2 Interpreter Sp=0x7f4257fc0168 SpLim=0x7f4257fc00c0 headroom = 21 Interpreter Sp=0x7f4257fc0200 SpLim=0x7f4257fc00c0 headroom = 40 Interpreter Sp=0x7f4257fc80b0 SpLim=0x7f4257fc80c0 headroom = -2 <---- NB Interpreter Sp=0x7f4257fc8148 SpLim=0x7f4257fc80c0 headroom = 17 Interpreter Sp=0x7f4257fc81e0 SpLim=0x7f4257fc80c0 headroom = 36 Interpreter Sp=0x7f4257fd0228 SpLim=0x7f4257fd00c0 headroom = 45 Interpreter Sp=0x7f4257fe0228 SpLim=0x7f4257fe00c0 headroom = 45 Interpreter Sp=0x7f4257fe8140 SpLim=0x7f4257fe80c0 headroom = 16 Interpreter Sp=0x7f4257fe81d8 SpLim=0x7f4257fe80c0 headroom = 35 Interpreter Sp=0x7f4257ff0120 SpLim=0x7f4257ff00c0 headroom = 12 Interpreter Sp=0x7f4257ff01b8 SpLim=0x7f4257ff00c0 headroom = 31 Interpreter Sp=0x7f4257ff8100 SpLim=0x7f4257ff80c0 headroom = 8 Interpreter Sp=0x7f4257ff8198 SpLim=0x7f4257ff80c0 headroom = 27 Interpreter Sp=0x7f4257ff8230 SpLim=0x7f4257ff80c0 headroom = 46 Interpreter Sp=0x7f4264a060e0 SpLim=0x7f4264a060c0 headroom = 4 Interpreter Sp=0x7f4264a06178 SpLim=0x7f4264a060c0 headroom = 23 Interpreter Sp=0x7f4264a06210 SpLim=0x7f4264a060c0 headroom = 42 Interpreter Sp=0x7f4264a0e0c0 SpLim=0x7f4264a0e0c0 headroom = 0 Interpreter Sp=0x7f4264a0e158 SpLim=0x7f4264a0e0c0 headroom = 19 Interpreter Sp=0x7f4264a0e1f0 SpLim=0x7f4264a0e0c0 headroom = 38 Interpreter Sp=0x7f4264a16138 SpLim=0x7f4264a160c0 headroom = 15 Interpreter Sp=0x7f4264a161d0 SpLim=0x7f4264a160c0 headroom = 34 Interpreter Sp=0x7f4264a1e118 SpLim=0x7f4264a1e0c0 headroom = 11 }}} So yes, we get into a situation in which we have negative headroom. Presumably if the ASSERT is off, we simply don't notice. But it's clearly wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9765: Strange behavior of GC under ghci
by GHC 06 Nov '14

06 Nov '14

#9765: Strange behavior of GC under ghci -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Releasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer. When I run something like this in GHCI: {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] > performGC > ^D Leaving GHCi. [1] 3782 segmentation fault (core dumped) ghci }}} it wont crash until exit from ghci which is correct. But if I do something similar but using `let` binding it will crash even if variable `a` didn't lose its scope {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > let a = Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] [1] 3842 segmentation fault (core dumped) ghci }}} Why is there a difference between doing it with `do` notation and with `let` binding? I also expected that if I rebind variable `a` it will lose it's scope and will be released but it is not (see below) {{{#!hs > import System.Mem > import Foreign.Ptr > import Foreign.ForeignPtr > import System.IO.Unsafe > import qualified Data.Map as Map > a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. > print a fromList [(1,0x0000000000000000)] > a <- return () -- rebinding varable a, it is no longer used > performGC > -- no crash, varaible a not released }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7192: Bug in -fregs-graph with -fnew-codegen
by GHC 05 Nov '14

05 Nov '14

#7192: Bug in -fregs-graph with -fnew-codegen -------------------------------------+------------------------------------- Reporter: simonmar | Owner: benl Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4258 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): This is marked as fixed, but the `-fregs-graph` flag is still disabled for `-O` and `-O2`. Can I re-enabled it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7192#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9773: Binding ImplicitParams in lambda results in parse error
by GHC 05 Nov '14

05 Nov '14

#9773: Binding ImplicitParams in lambda results in parse error -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ImplicitParams}}} currently do not play well with lambdas :( == Steps to reproduce Create a file {{{Foo.hs}}} with the following content: {{{ {-# LANGUAGE ImplicitParams #-} import Control.Monad foo :: (?bar :: Int) => IO () foo = print ?bar main = do forM_ [1..3] $ \ ?bar -> foo }}} === Expected result {{{ $ runhaskell Foo.hs 1 2 3 }}} === Actual result {{{ $ runhaskell Foo.hs Foo.hs:9:21: Parse error in pattern: ?bar }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7942: aarch64 support in ghc
by GHC 05 Nov '14

05 Nov '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by lukexi): * status: new => patch Comment: Hello! This patch finishes ARM64 support including SMP and means we can now run on the newest 64-bit iOS devices. Would be awesome to get this into 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:51> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0