- ghc-tickets - Haskell.org

Re: [GHC] #7353: Make system IO interruptible on Windows
by GHC 24 Mar '16

24 Mar '16

#7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: 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 refold): I will be spending the next two months working on this ticket, picking up where @joeyadams left off. My intention is to produce a patchset suitable for inclusion for GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7353#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11676: Preserve name of original function in worker name
by GHC 24 Mar '16

24 Mar '16

#11676: Preserve name of original function in worker name -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently it's not uncommon to find workers named, e.g., `$wa` while perusing Core. When you find one of these you need to then go searching for its associated wrapper to discover which function the worker implements. Then you need to work hard to keep this piece of information in your mental state. This is unfortunate and makes reading Core unnecessarily hard. Why not name the worker of `thisIsAFunction` something like, e.g., `thisIsAFunction$wa`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11595: Merge some TypeInType fixes
by GHC 24 Mar '16

24 Mar '16

#11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There were several commits I just pushed that should be merged, but there is no associated ticket. b962bcc609cf3239d61ba281ca0eccc3cd89d99d 90f35612f16ff9cb2466cc936f12e748402abb85 aff5bb47b70450bb1e3e4ac3c18ea35d13f9ac7c 7d8031ba3d36a9378a40834aa3e3817d8f7f310f 6f952f58bc4d592265134e4e13af46da9c56560f -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11595> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11707: Don't desugar large lists with build
by GHC 24 Mar '16

24 Mar '16

#11707: Don't desugar large lists with build -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | 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: -------------------------------------+------------------------------------- When looking at `T9661` I noticed that a massive list was being inlined into `listArray`, where foldr/build was being applied, turning a bunch of massive static data into a massive block of code. It seems likely that keeping this as static data would be preferable here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11707> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11701: ghc generates significant slower code
by GHC 24 Mar '16

24 Mar '16

#11701: ghc generates significant slower code -------------------------------------+------------------------------------- Reporter: HuStmpHrrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: efficiency | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've already started a discussion here in SO: http://stackoverflow.com/questions/35941674/latest-ghc-generates-slower- code So again, I realized that the latest version of ghc produces significantly slower code than older version. my default ghc is the latest version as of now: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} I have also two other old versions installed in my local machine. test code as following {{{#!hs import Data.Word import Data.List import System.Environment collatzNext :: Word32 -> Word32 collatzNext a = (if even a then a else 3*a+1) `div` 2 -- new code collatzLen :: Word32 -> Int collatzLen a0 = lenIterWhile collatzNext (/= 1) a0 lenIterWhile :: (a -> a) -> (a -> Bool) -> a -> Int lenIterWhile next notDone start = len start 0 where len n m = if notDone n then len (next n) (m+1) else m -- End of new code main = do [a0] <- getArgs let max_a0 = (read a0)::Word32 print $ maximum $ map (\a0 -> (collatzLen a0, a0)) [1..max_a0] }}} following are the three runs in my machine: {{{ $ ~/Tools/ghc-7.6.1/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m1.901s user 0m1.896s sys 0m0.000s $ ~/Tools/ghc/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m10.562s user 0m10.528s sys 0m0.036s $ ~/Tools/ghc-7.4.2/bin/ghc -O2 Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ time ./Test 1000000 (329,837799) real 0m1.879s user 0m1.876s sys 0m0.000s }}} Obviously we can tell latest version of ghc produces worse code than the older two versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11456: Type application and :set +c command cause panic
by GHC 23 Mar '16

23 Mar '16

#11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications GHCi | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type applications and the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:set%20+c :set +c] command don't play nice {{{#!hs {-# LANGUAGE TypeApplications #-} a = show @Int }}} {{{ % ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> :set +c Prelude> :load Panic.hs [1 of 1] Compiling Main ( Panic.hs, interpreted ) Ok, modules loaded: Main. Collecting type info for 1 module(s) ... Error while getting type info from Main: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): dsExpr:HsTypeOut Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11716: Make TypeInType stress test work
by GHC 23 Mar '16

23 Mar '16

#11716: Make TypeInType stress test work -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I used the attached file during my job talk. It is good `TypeInType` stress test. This bug is to track several fixes that have been necessary to get it working. I have these fixes locally and will push in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11712: Very confusing error message with -fprint-explicit-kinds
by GHC 23 Mar '16

23 Mar '16

#11712: Very confusing error message with -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to work out a type error I encountered the following, {{{ compiler/utils/Binary.hs:607:59: error: • Could not deduce: (~) * * arg * from the context: (~) * k (arg -> res) ... }}} Note how in the first line `(~)` is applied to four arguments whereas on the second it is applied to three. In general, it would be nice if we could make equalities a bit more readable, perhaps special-casing them in the pretty-printer as, {{{ (a :: k) ~ (b :: k') }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11512: An unwritten kind variable is "specified", when it shouldn't be.
by GHC 23 Mar '16

23 Mar '16

#11512: An unwritten kind variable is "specified", when it shouldn't be. -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails: {{{#!hs {-# LANGUAGE PolyKinds, TypeApplications, ScopedTypeVariables #-} module Bug where import Data.Proxy class C a where foo :: Proxy a bar :: forall a. C a => Proxy a bar = foo @a }}} But it really should work, because the invisible kind variable to class `C` should not be available for type application. On the last line, `foo @_ @a` works, when you explicitly instantiate the kind variable. Also, saying `:t foo` in GHCi shows the specified kind variable. Will fix. At some point. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11684: Fix tests with Clang
by GHC 23 Mar '16

23 Mar '16

#11684: Fix tests with Clang -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Configuring GHC with `--with-gcc=clang` and then running the tests currently causes over 100 test failues. The vast majority are due to stderr differences due to Clang producing more warnings, specifically `warning: argument unused during compilation`. The obvious solution would be to filter these out in the testsuite runner. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14