August 2016 - ghc-tickets

[GHC] #9112: data families with representational matching
by GHC 17 Oct '17

17 Oct '17

#9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth
by GHC 17 Oct '17

17 Oct '17

#10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The problem observed on GHC's code base when explored why exactly some object files are so huge. Let's look at the stats of text code section sizes on today's HEAD (skipping GHCi libraries and stage1 binaries): {{{ ~/dev/git/ghc $ size `find -name *.o -type f | grep -v stage1 | grep -v HS` | sort -k1 -n -r | head -n20 text data bss dec hex filename 1791068 145448 0 1936516 1d8c84 ./compiler/stage2/build/DynFlags.o 1558637 77464 0 1636101 18f705 ./compiler/stage2/build/PprC.o 1397966 23272 0 1421238 15afb6 ./compiler/stage2/build/PlatformConstants.o 1332048 373344 0 1705392 1a05b0 ./libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription.o 1331238 373352 0 1704590 1a028e ./bootstrapping/Distribution/PackageDescription.o 1271578 246240 0 1517818 1728fa ./libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 1229696 311616 0 1541312 1784c0 ./libraries/Cabal/Cabal/dist- install/build/Distribution/PackageDescription.o 1215082 224288 0 1439370 15f68a ./libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.o 1071746 242664 0 1314410 140e6a ./compiler/stage2/build/HsExpr.o 1015090 40904 0 1055994 101cfa ./compiler/stage2/build/Llvm/PpLlvm.o 970203 124944 0 1095147 10b5eb ./compiler/stage2/build/Parser.o 849693 79760 0 929453 e2ead ./compiler/stage2/build/HsDecls.o 833327 35440 0 868767 d419f ./compiler/stage2/build/X86/CodeGen.o 819959 127192 0 947151 e73cf ./libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Setup.o 819685 125120 0 944805 e6aa5 ./bootstrapping/Distribution/Simple/Setup.o 816927 124520 0 941447 e5d87 ./libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.o 785398 41536 0 826934 c9e36 ./compiler/stage2/build/CoreLint.o 772550 42040 0 814590 c6dfe ./compiler/stage2/build/DriverPipeline.o 766461 36280 0 802741 c3fb5 ./compiler/stage2/build/HscMain.o 735605 23408 0 759013 b94e5 ./libraries/containers/dist- install/build/Data/Sequence.o }}} '''PlatformConstants.o''' is a very clear example of this problem. Trimmed down example of this file is: {{{#!hs module M (D) where data D = D { a0 , a01 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , a10 , a11 , a12 , a13 , a14 , a15 , a16 , a17 , a18 , a19 , a20 , a21 , a22 , a23 , a24 , a25 , a26 , a27 , a28 , a29 , a30 , a31 , a32 , a33 , a34 , a35 , a36 , a37 , a38 , a39 , a40 , a41 , a42 , a43 , a44 , a45 , a46 , a47 , a48 , a49 , a50 , a51 , a52 , a53 , a54 , a55 , a56 , a57 , a58 , a59 , a60 , a61 , a62 , a63 , a64 , a65 , a66 , a67 , a68 , a69 , a70 , a71 , a72 , a73 , a74 , a75 , a76 , a77 , a78 , a79 , a80 , a81 , a82 , a83 , a84 , a85 , a86 , a87 , a88 , a89 , a90 , a91 , a92 , a93 , a94 , a95 , a96 , a97 , a98 , a99 :: Int } deriving Read }}} Results in 800KB file: {{{ $ ghc-stage2 -c -O1 -fforce-recomp M.hs -o M.o $ size M.o text data bss dec hex filename 847039 16080 0 863119 d2b8f M.o }}} The size growth is quadratic: {{{ # fields code-size 1 6263 21 61767 41 173623 61 347503 81 583367 101 881231 121 1241087 141 1662959 161 2146815 181 2692679 201 3300543 221 3970407 241 4702263 261 5496135 281 6351991 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11262: Test print022: wrong stdout on powerpc64
by GHC 16 Oct '17

16 Oct '17

#11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: print022 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi prints a NUL(?) character instead of an 'x'. {{{ () -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23 Breakpoint 0 activated at print022.hs:11:1-7 Stopped at print022.hs:11:1-7 _result :: r = _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI
by GHC 16 Oct '17

16 Oct '17

#9274: GHC panic with UnliftedFFITypes+CApiFFI -----------------------------------+--------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following code fails to compile with at least GHC 7.6, 7.8 and HEAD: {{{#!hs import GHC.Prim import Foreign.C type GmpLimb = CULong type GmpSize = CLong -- mp_limb_t mpn_add_1 (mp_limb_t *rp, const mp_limb_t *s1p, mp_size_t n, mp_limb_t s2limb) foreign import capi unsafe "gmp.h mpn_add_1" c_mpn_add_1 :: MutableByteArray# s -> ByteArray# -> GmpSize -> GmpLimb -> IO GmpLimb }}} with the following compile error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140704 for x86_64-unknown-linux): toCType MutableByteArray# s Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Otoh, replacing `capi` with `ccall` makes the code compile just fine -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11654: User Guide: Generate command line options table from ghc-flags directives
by GHC 11 Oct '17

11 Oct '17

#11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.3 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: -------------------------------------+------------------------------------- Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flags` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10816: Fixity declaration for associated type rejected
by GHC 11 Oct '17

11 Oct '17

#10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ‘#’ is not a (visible) method of class ‘C’ }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics
by GHC 04 Oct '17

04 Oct '17

#11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Pat (Vec2(Nil,(:>)), pattern (:>)) where newtype Vec2 a = Vec2 {unvec2 :: [a]} pattern Nil :: Vec2 a pattern Nil = Vec2 [] pattern (:>) x xs <- ((\ys -> (head $ unvec2 ys,Vec2 . tail $ unvec2 ys)) -> (x,xs)) where (:>) x xs = Vec2 (x:unvec2 xs) }}} and {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Main where import Pat (Vec2(..),pattern (:>)) }}} I get: {{{ $ ghci Main.hs GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling Pat ( Pat.hs, interpreted ) Pat.hs:2:29: warning: [-Wduplicate-exports] ‘:>’ is exported by ‘(:>)’ and ‘Vec2(Nil, type (:>))’ [2 of 2] Compiling Main ( Main.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160411 for x86_64-unknown-linux): filterImports/combine (:>, :>, Nothing) (:>, Vec2{Vec2, :>, Nil}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Now, the warning about the duplicate export is of course correct. But the panic shouldn't happen when I try to import both the associated pattern synonym and the normal pattern synonym. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9725: Constraint deduction failure
by GHC 03 Oct '17

03 Oct '17

#9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I get a strange error message like this {{{ [1 of 1] Compiling Main ( 08-10.hs, interpreted ) 08-10.hs:254:33: Could not deduce (KnownLoc (ent par1 a)) arising from a use of ‘Hidden'’ from the context (List ConfFamily ts) bound by the type signature for locAware :: List ConfFamily ts => (forall (i :: k). KnownLoc (ent par i) => ConfFamily (Facility (ent par i)) ts) -> Con ConfFamily (On ent par) at 08-10.hs:251:13-160 or from (ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp)) bound by a pattern with constructor MonitorF :: forall (par :: Entity) (mp :: MonitorPoint). KnownLoc ('Monitor par mp) => String -> String -> Observer -> Bool -> Facility ('Monitor par mp), in an equation for ‘h’ at 08-10.hs:254:19-28 In the expression: Hidden' (d f) In an equation for ‘h’: h (Hide f@(MonitorF {})) = Hidden' (d f) In an equation for ‘locAware’: locAware descr = Abstr h where h :: (ent `On` par) -> ConfFamily (ent `On` par) ts h (Hide f@(MonitorF {})) = Hidden' (d f) d :: KnownLoc (ent par i) => Facility (ent par i) -> ConfFamily (Facility (ent par i)) ts d _ = descr Failed, modules loaded: none. }}} I have many language extensions active, such as, `DataKinds`, `ScopedTypeVariables`, etc. If somebody says this indeed looks like a bug, then I'll try to post a minimal reproduction case. ** My reasoning goes like this ** Here are the relevant facts that GHC figured out from a GADT pattern match: `(ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp))` From this I discover these equalities: {{{ ent === 'Monitor (*) par === par1 (**) a === mp (***) }}} Substituring `(*)`^-1^ and `(***)`^-1^ into the given `KnownLoc ('Monitor par1 mp)` results in the desired `KnownLoc (ent par1 a)` Looks like a bug, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #9198: large performance regression in type checker speed in 7.8
by GHC 02 Oct '17

02 Oct '17

#9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- it was recently demonstrated on the haskell-cafe mailing list that the following code takes measurably longer to type check in GHC 7.8.2 than in GHC 7.6. http://www.haskell.org/pipermail/haskell-cafe/2014-June/114562.html the program example is as follows {{{ begin cont = cont (return ()) a m =cont (m >> putstrn "a") end m = m main = begin a a a a a a a a a a a a a a a a a end }}} takes about a second to type check in ghc 7.8, and is "instant" in 7.6 () each additional a doubles the time to type check the program {{{ main = begin a a a a a a a a a a a a a a a a a a a a a a a a end }}} takes longer than I have the patience to wait :) (so more than 5 seconds) the author of the email notes that a related program {{{ main = id id id id id id id id id id id id id id id id id id id id id id (return ()) }}} has the exponential complexity in both 7.8.2 and 7.6.2 This It could very well be that some of the type checker changes between 7.8 and 7.6 enlarged the space of programs that trip up exponential worst case behavior, but one way or another understanding *why* this happened -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation
by GHC 02 Oct '17

02 Oct '17

#11771: ghc.exe: `panic'! (the 'impossible' happened); thread blocked indefinitely in an MVar operation ----------------------------------------+------------------------------- Reporter: YoYoYonnY | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Here's a "fun" one: {{{#!hs *Main> main Interrupted. *Main> *Main> !cl ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} Don't mind the {{{!cl}}}, GHC crashed as soon as the interupt was registered, I usually {{{:!cls}}} after I execute main. I will backup the code in case someone wants to see if it's a bug in my program, but I didn't use multithreading myself, and I don't think the vector, unordered-containers, bytestring and parsec packages use threading either (all heavily at work, though)... The interupt was nececairy because my code was generating a infinite (oops) collection of these bad boys, using all sorts of folds, maps, etc.: {{{#!hs newtype ParserData = ParserData { unpackParserData :: HashMap ByteString (ParserData -> Either ByteString (Parser ())) } }}} I am wondering if this could be a problem with Windows, because the system was running slow at the time of the interupt; The {{{Alt+Tab}}} screen didn't appear until after the interupt. I don't think I can manage to reproduce this bug, which is unfortunate aswell (low priority because of that :c). Either way, it crashed, that's all I can tell you for sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3