- ghc-tickets - Haskell.org

Re: [GHC] #5291: GhcDynamic build fails on Windows: can't find DLLs
by GHC 05 Jan '17

05 Jan '17

#5291: GhcDynamic build fails on Windows: can't find DLLs -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Build System | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5291#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5620: Dynamic linking and threading does not work on Windows
by GHC 05 Jan '17

05 Jan '17

#5620: Dynamic linking and threading does not work on Windows -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5620#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 05 Jan '17

05 Jan '17

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 Comment: Punting this as I've been too busy to finish the patch. But I now have worked out how I can solve the remaining issues so should be able to wrap it up for 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:62> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 05 Jan '17

05 Jan '17

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5344: CSE should look through coercions
by GHC 05 Jan '17

05 Jan '17

#5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hah, you confused me by writing this comment before updating #9291 :) This example seems easier than the original example in #9291 though, since `f` can be expressed using a cast as a well-typed program in the current Core language. All else being equal, it seems better to do the CSE earlier rather than later, though I'm not sure whether it makes an actual difference in practice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5344#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5344: CSE should look through coercions
by GHC 05 Jan '17

05 Jan '17

#5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: duplicate | Keywords: cse Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate Comment: I think this is covered as good as it can be for now by doing CSE on STG, where the coercion is gone (see #9291). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5344#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 05 Jan '17

05 Jan '17

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi @refold, Just checking in to see if you're still working on this. If not would you be able to let me know your last status? This is on the list of major Windows changes I want to target for 8.4. I assume this is your repository? https://github.com/23Skidoo/haskell-iocp -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13051: Make the Register Allocator Loop-Aware
by GHC 05 Jan '17

05 Jan '17

#13051: Make the Register Allocator Loop-Aware -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D2903 | Wiki Page: -------------------------------------+------------------------------------- Currently the graph coloring register allocator has 2 spill cost functions: one that implements Chaitin’s spill cost function and one that just spills the longest live range. We currently use the latter. Neither of them have any knowledge of program structure’ the register allocator basically assumes all code runs an equal number of times and therefore it doesn’t matter where you insert spills. By making it aware of loops and biasing it to avoid spilling in them when possible loops can run significantly faster. Obviously we don’t actually write loops in Haskell but we definitely still have them underneath our abstractions. Since we don’t write them explicitly we have to find them in our output (which is what the bulk of LoopAnnotations.hs does). A loop is just a place where control flow doubles back on itself, so we walk through the jumps (we already know where these are because the output has been divided into basic blocks) and try to find places where that happens. Currently if we have virtual registers born before a loop that are used in a large number of instructions before and after the loop but not in it we’ll avoid spilling them because it looks like we’ll have to reload them right away. In reality we won’t use them until the end of the loop which might be an order of magnitude of clock cycles later. So we’ll spill something else inside the loop which means every time the loop runs we run spill code. The goal is to have more intelligently placed spills and reloads instead of simply minimizing the number of them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures
by GHC 05 Jan '17

05 Jan '17

#13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Giving GHC 8.0.2rc2 a closer look I stumbled over this one: This works fine in GHC 7.10.3, but fails to compile with GHC 8.0.2rc2: {{{ Resolving dependencies... In order, the following will be built (use -v for more details): - vivid-0.1.0.3 {vivid-0.1.0.3-inplace} (lib) (first run) Configuring component lib from vivid-0.1.0.3... Preprocessing library vivid-0.1.0.3... [ 1 of 10] Compiling Vivid.SynthDef.Types ( Vivid/SynthDef/Types.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/Types.o ) [ 2 of 10] Compiling Vivid.SynthDef.CrazyTypes ( Vivid/SynthDef/CrazyTypes.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/CrazyTypes.o ) [ 3 of 10] Compiling Vivid.OSC.Util ( Vivid/OSC/Util.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/OSC/Util.o ) [ 4 of 10] Compiling Vivid.SynthDef.Literally ( Vivid/SynthDef/Literally.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/Literally.o ) [ 5 of 10] Compiling Vivid.OSC ( Vivid/OSC.hs, /tmp/vivid-0.1.0.3 /dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/OSC.o ) [ 6 of 10] Compiling Vivid.SCServer ( Vivid/SCServer.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SCServer.o ) /tmp/ghc12095_0/ghc_27.s: Assembler messages: /tmp/ghc12095_0/ghc_27.s:5860:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined /tmp/ghc12095_0/ghc_27.s:10988:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined /tmp/ghc12095_0/ghc_27.s:11751:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined `gcc' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12679: Permit abstract data types in signatures that don't have kind *
by GHC 05 Jan '17

05 Jan '17

#12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a fascinating program that I would like to write, but cannot with Backpack today: {{{ unit p where signature Key where import GHC.Exts (Constraint) data Key k :: Constraint instance Key Bool signature Map where import Key data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a signature Keys where import Map module M where import Map import Key x = insert True "foo" empty }}} `data Key k :: Constraint` is implementable, because we can implement abstract data types using type synonyms in Backpack, and synonyms can have more kinds than just `*`. However, GHC chokes on this declaration, because it thinks that data types always have to have kind `*`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8