July 2014 - ghc-tickets

[GHC] #9011: panic - interactiveUI:setBuffering2
by GHC 06 Nov '14

06 Nov '14

#9011: panic - interactiveUI:setBuffering2 ----------------------------------+------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- I've looked through some other tickets and tried installing libffi5, though in my distro (Kubuntu 13.10 x86-64) only libffi6 is available. Even after installing that I get the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): interactiveUI:setBuffering2 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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

[GHC] #9211: Untouchable type variable (regression from 7.6)
by GHC 04 Nov '14

04 Nov '14

#9211: Untouchable type variable (regression from 7.6) ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Oleg says: what used to type check in GHC 7.4.1 (and I think in 7.6.2, although I no longer have access to that version) fails in GHC 7.8.2. The following program type-checks with GHC 7.4.1 and GHC 7.8.2: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] -- foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} The following code (which differs only in the signature of foo) {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module T where -- foo :: (forall f g. (Functor f) => f a -> f b) -> [a] -> [b] foo :: (forall f g. (Functor f, g ~ f) => g a -> g b) -> [a] -> [b] foo tr x = tr x t = foo (fmap not) [True] }}} type-checks with 7.4.1 but not with 7.8.2. The latter reports the error {{{ Couldn't match type `b' with `Bool' `b' is untouchable inside the constraints (Functor f, g ~ f) bound by a type expected by the context: (Functor f, g ~ f) => g Bool -> g b at /tmp/t.hs:12:5-25 `b' is a rigid type variable bound by the inferred type of t :: [b] at /tmp/t.hs:12:1 Expected type: Bool -> b Actual type: Bool -> Bool Relevant bindings include t :: [b] (bound at /tmp/t.hs:12:1) In the first argument of `fmap', namely `not' In the first argument of `foo', namely `(fmap not)' }}} Giving `t` the type signature `[Bool]` fixes the problem. Alas, I come across the similar untouchable error in situations where giving the type signature is quite difficult (in local bindings, with quite large types). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9081: Template Haskell gets confused with scoped kind variables in a class declaration
by GHC 04 Nov '14

04 Nov '14

#9081: Template Haskell gets confused with scoped kind variables in a class declaration ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TemplateHaskell, DataKinds, PolyKinds, TypeFamilies #-} module Bug where import Data.Proxy $( [d| class kproxy ~ 'KProxy => C (kproxy :: KProxy a) where type TF (x :: a) :: Bool |]) }}} I get {{{ /Users/rae/temp/Bug.hs:7:4: Kind variable also used as type variable: ‘a_asJA’ In the declaration for class C_asJy /Users/rae/temp/Bug.hs:7:4: The exact Name ‘kproxy_asJB’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful }}} The code in the TH quote compiles fine on its own. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8482: Permission denied when copying file to current directory with copyFile
by GHC 03 Nov '14

03 Nov '14

#8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: Windows Keywords: copyFile | Type of failure: Incorrect result permission denied | at runtime Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- While the MS-DOS command {{{ C:\tmp\b>copy c:\tmp\a\x }}} runs successfully, the Haskell equivalent {{{ copyFile "c:\\tmp\\a\\x" "" }}} results in {{{ copyFile.hs: .\.copyFile584.tmp: copyFile: does not exist (Het systeem kan het opgegeven pad niet vinden.) }}} The Dutch explanation says: "The system can not find the specified path" {{{ copyFile "c:\\tmp\\a\\x" "." }}} results in {{{ copyFile.hs: .\.copyFile3960.tmp: copyFile: permission denied (Toegang geweigerd.) }}} The Dutch explanation says: "Access denied" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9359: Deriving clause failure with polymorphic kinds
by GHC 03 Nov '14

03 Nov '14

#9359: Deriving clause failure with polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider {{{ {-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-} module Fam where data Cmp a where Sup :: Cmp a V :: a -> Cmp a deriving (Show, Eq) data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: * data instance CmpInterval (V c) Sup = Starting c deriving( Show ) }}} GHC 7.8.3 gives {{{ Fam.hs:12:13: Can't make a derived instance of ‘Show (CmpInterval ('V c) 'Sup)’: No family instance for ‘CmpInterval ('V c) 'Sup’ In the data instance declaration for ‘CmpInterval’ }}} which is obviously wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9359> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2
by GHC 03 Nov '14

03 Nov '14

#8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -----------------------------------+--------------------------------------- Reporter: MichalGajda | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: cabal install hPDB Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- GHC 7.8 rc2 exhausts all memory on `Bio.PDB.EventParser.PDBEventParser` module in -O3 mode, but not in -O2 mode. The tail of ''-v3'' input seems to indicate that it dies during SpecConstr phase. The module successfully compiled with below 2GB RAM since GHC 6.12, so I wonder why the memory use exploded with the most recent version. *** SpecConstr: ==================== SpecConstr ==================== Result size of SpecConstr STEPS TO REPRODUCE: 1. `cabal install hPDB` RESULT EXPECTED: Successful compilation and installation CURRENT RESULT: Exhausts available memory and crashes when compiling `Bio.PDB.EventParser.PDBEventParser`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8819: Testsuite failures in 7.8 RC1
by GHC 03 Nov '14

03 Nov '14

#8819: Testsuite failures in 7.8 RC1 ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- With the recent patches applied to RC1 I managed to bootstrap an unregisterised ghc. Running the testsuite I get the following failures on Linux x86_64: {{{ Unexpected failures: ../../libraries/base/tests fixed [bad stdout] (normal) ../../libraries/base/tests/Numeric num010 [bad stdout] (normal) ../../libraries/process/tests process007 [bad exit code] (normal) codeGen/should_compile T7574 [stderr mismatch] (normal) codeGen/should_gen_asm memcpy [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll [asm mismatch] (normal) codeGen/should_gen_asm memcpy-unroll-conprop [asm mismatch] (normal) codeGen/should_run T2838 [bad stdout] (normal) lib/integer integerBits [bad stdout] (normal) lib/integer integerConversions [bad stdout] (normal) numeric/should_run T8726 [bad exit code] (normal) numeric/should_run arith002 [bad stdout] (normal) numeric/should_run arith003 [bad stdout] (normal) numeric/should_run arith004 [bad stdout] (normal) numeric/should_run arith005 [bad stdout] (normal) numeric/should_run arith011 [bad stdout] (normal) numeric/should_run arith012 [bad stdout] (normal) numeric/should_run arith014 [bad stdout] (normal) parser/should_run readRun002 [bad stdout] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/should_run T3736 [bad stderr] (normal) rts T5423 [bad stderr] (normal) rts T7815 [bad exit code] (threaded1) safeHaskell/check/pkg01 safePkg01 [bad stderr] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8849: Unregisterised compiler: arithmetic failure
by GHC 03 Nov '14

03 Nov '14

#8849: Unregisterised compiler: arithmetic failure --------------------------+------------------------------------------------ Reporter: | Owner: trommler | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.1-rc2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: arith005 Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: #8819 | --------------------------+------------------------------------------------ Compiling the following with RC2 on powerpc 64 downloaded from haskell.org: {{{ main = putStr $ show (-1.0000000001 :: Double) }}} Setting {{{-O}}} yields: {{{ 0.0 }}} Without optimization the correct result is displayed. I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8849> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9345: Data.List.inits is extremely slow
by GHC 03 Nov '14

03 Nov '14

#9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Easy (less Test Case: | than 1 hour) Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- As discussed on libraries(a)haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in the attached) is a one-liner and gives very good performance in general, but poor performance in certain cases that may or may not appear in real code. The other (named `initsQ` in the attached) is slightly more complex and slightly slower in general, but its performance appears to be robust. I would personally lean toward `initsQ` for `Data.List`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34