August 2014 - ghc-tickets

[GHC] #9508: Rename package key
by GHC 04 Jan '15

04 Jan '15

#9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We were planning on renaming package key to something different. The two proposals on the table are "package instance" (which I don't like) and "library ID". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9495: Do What I Mean RULES for foldr2 look shady
by GHC 02 Jan '15

02 Jan '15

#9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment in the source: {{{ The foldr2/right rule isn't exactly right, because it changes the strictness of foldr2 (and thereby zip) E.g. main = print (null (zip nonobviousNil (build undefined))) where nonobviousNil = f 3 f n = if n == 0 then [] else f (n-1) I'm going to leave it though. }}} This rule is intended to allow `foldr2` to fuse with ''either'' argument list. There are thus two problems, one already documented and the other not: 1. The rule can turn working code into non-working code, although this seems to be ''relatively'' unlikely. (The problem the above example is showing is that if the left list ends at the same time the right list bottoms out, the world goes boom. So `foldr2 f [1,2,3,4] (1:2:3:4:undefined)` appears to be a problem. You could argue this is not a big deal, I suppose. 2. The `foldr2/left` and `foldr2/right` rules are not confluent. They are both active in all phases, but if both list arguments are good producers, they will each want to rewrite the expression differently. So if you actually care about which one fuses, you need to explicitly block fusion with one argument using `NOINLINE`, which of course could easily muck up some other optimization. My uninformed opinion: nix the `foldr2/right` rule, and change the documentation to indicate that `foldr2` fuses with its ''left'' argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery
by GHC 28 Dec '14

28 Dec '14

#9067: Optimize clearNursery by short-circuiting when we get to currentNursery ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested): {{{ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 36776b9..0311042 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -598,6 +598,11 @@ clearNursery (Capability *cap) ASSERT(bd->gen_no == 0); ASSERT(bd->gen == g0); IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE)); + if (bd == cap->r.rCurrentNursery) { + IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link) + ASSERT(bd->free == bd->start)); + break; + } } } } }}} This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9032: Panic with self-import
by GHC 27 Dec '14

27 Dec '14

#9032: Panic with self-import -----------------------------------+--------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I've run into GHC panic with this code: {{{ {-# OPTIONS_GHC -fno-warn-unused-imports #-} module Singletons.Star where import Data.Singletons.Prelude import Data.Singletons.Decide import Data.Singletons.CustomStar import Singletons.Nat import Singletons.Star -- <------- HERE data Vec :: * -> Nat -> * where VNil :: Vec a Zero VCons :: a -> Vec a n -> Vec a (Succ n) $(singletonStar [''Nat, ''Int, ''String, ''Maybe, ''Vec]) }}} This is a test in `singletons` package that leads to a panic when run: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I was unable to minimize the test case. Reproducing requires following steps: 1. Installing latest th-desugar library from github: {{{ git clone https://github.com/goldfirere/th-desugar.git cd th-desugar cabal install }}} 2. Getting latest development version of singletons: {{{ git clone https://github.com/goldfirere/singletons cd singletons git checkout 56734c2bda721cb9a6a3021b901e3b29d6564f0c make tests }}} All should go well. Now you need to edit file `tests/compile-and- dump/Singletons/Star.hs` and uncomment `import Singletons.Star` line. It should be possible to reproduce the bug with: {{{ cd tests/compile-and-dump/ghc -package-name singletons-1.0 Singletons/Star.hs -i../../dist/build -c -XTemplateHaskell }}} It's important to run `make tests` first so that all interface files required by `Star.hs` are in place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9032> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol'
by GHC 24 Dec '14

24 Dec '14

#8696: linking fails with 'relocation R_X86_64_PC32 against undefined symbol' ----------------------------------+------------------------------ Reporter: Kata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------ Building ekmett's lens package from HEAD (revision 80c1fddf) with the following error fragment: {{{ Last 10 lines of the build log ( /home/kata/.cabal/logs/lens-4.0.log ): [77 of 85] Compiling Data.Vector.Lens ( src/Data/Vector/Lens.hs, dist/build/Data/Vector/Lens.o ) [78 of 85] Compiling Data.Vector.Generic.Lens ( src/Data/Vector/Generic/Lens.hs, dist/build/Data/Vector/Generic/Lens.o ) [79 of 85] Compiling Generics.Deriving.Lens ( src/Generics/Deriving/Lens.hs, dist/build/Generics/Deriving/Lens.o ) [80 of 85] Compiling GHC.Generics.Lens ( src/GHC/Generics/Lens.hs, dist/build/GHC/Generics/Lens.o ) [81 of 85] Compiling System.Exit.Lens ( src/System/Exit/Lens.hs, dist/build/System/Exit/Lens.o ) [82 of 85] Compiling System.FilePath.Lens ( src/System/FilePath/Lens.hs, dist/build/System/FilePath/Lens.o ) [83 of 85] Compiling System.IO.Error.Lens ( src/System/IO/Error/Lens.hs, dist/build/System/IO/Error/Lens.o ) /usr/bin/ld: dist/build/Control/Lens/TH.dyn_o: relocation R_X86_64_PC32 against undefined symbol `lenszm4zi0_ControlziLensziInternalziTH_appsE1zulgo_info' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: lens-4.0 failed during the building phase. The exception was: ExitFailure 1 }}} Full log is attached. I'm not trying to build with shared libraries, or profiling, or anything like that. I can reproduce this failure starting from a fresh Debian testing install as follows: 1. Bootstrap GHC HEAD. {{{ sudo aptitude install ghc=7.6.3-6 happy=1.19.0-1 alex=3.1.0-1 sudo apt-get build-dep ghc cd /var/tmp git clone git://git.haskell.org/ghc.git cd ghc git checkout e01367ff ./sync-all get ./boot ./configure # Adjust the -j option to taste. make -j4 sudo make install }}} 2. Bootstrap cabal-install. {{{ cd /var/tmp wget http://www.haskell.org/cabal/release/cabal-install-1.18.0.2/cabal- install-1.18.0.2.tar.gz -O - | tar xzf - cd cabal-install-1.18.0.2 patch -p3 < cabal-install-ghc-HEAD.patch # see attached sudo aptitude install zlib1g-dev ./bootstrap.sh export PATH=$HOME/.cabal/bin:$PATH cabal update }}} 3. Build lens. {{{ cd /var/tmp git clone https://github.com/ekmett/lens cd lens git checkout 80c1fddf cabal install cpphs cabal install # this fails }}} Using gcc Debian 4.8.2-14, ld 2.24. The GHC fingerprint and output of `ghc --info` is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
by GHC 22 Dec '14

22 Dec '14

#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints
by GHC 19 Dec '14

19 Dec '14

#9316: GHC 7.8.3 no longer infers correct type in presence of type families and constraints -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- The following code fails to compile under GHC 7.8.3: {{{ {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module SingletonsBug where import Control.Applicative import Data.Constraint (Dict(..)) import Data.Singletons import Data.Singletons.TH (singletons) import Data.Traversable (for) $(singletons [d| data SubscriptionChannel = BookingsChannel |]) type family T (c :: SubscriptionChannel) :: * type instance T 'BookingsChannel = Bool witnessC :: SSubscriptionChannel channel -> Dict (Show (T channel), SingI channel) witnessC SBookingsChannel = Dict forAllSubscriptionChannels :: forall m r. (Applicative m) => (forall channel. (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r forAllSubscriptionChannels f = withSomeSing BookingsChannel $ \(sChannel) -> case witnessC sChannel of Dict -> f sChannel }}} {{{ SingletonsBug.hs:38:15: Could not deduce (SingI channel0) arising from a use of ‘f’ from the context (Applicative m) bound by the type signature for forAllSubscriptionChannels :: Applicative m => (forall (channel :: SubscriptionChannel). (SingI channel, Show (T channel)) => SSubscriptionChannel channel -> m r) -> m r at SingletonsBug.hs:(32,6)-(34,8) or from ((Show (T a), SingI a)) bound by a pattern with constructor Dict :: forall (a :: Constraint). (a) => Dict a, in a case alternative at SingletonsBug.hs:38:7-10 The type variable ‘channel0’ is ambiguous Note: there is a potential instance available: instance SingI 'BookingsChannel -- Defined at SingletonsBug.hs:19:3 In the expression: f sChannel In a case alternative: Dict -> f sChannel In the expression: case witnessC sChannel of { Dict -> f sChannel } SingletonsBug.hs:38:17: Couldn't match type ‘channel0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: Sing a -> m r at SingletonsBug.hs:(36,3)-(38,24) Expected type: SSubscriptionChannel channel0 Actual type: Sing a Relevant bindings include sChannel :: Sing a (bound at SingletonsBug.hs:36:36) In the first argument of ‘f’, namely ‘sChannel’ In the expression: f sChannel }}} However, this works fine in GHC 7.8.2. If I change one line to this: {{{ withSomeSing BookingsChannel $ \(sChannel :: SSubscriptionChannel c) -> }}} The code compiles in GHC 7.8.3. Another change that doesn't require a type signature (but changes the program) is to change that constraint from: {{{ Show (T channel), SingI channel }}} to just {{{ SingI channel }}} It seems that the use of the type family breaks the inference, but this might be a bit of a red herring! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles
by GHC 19 Dec '14

19 Dec '14

#8984: Improve output of failed GeneralizedNewtypeDeriving coercion due to type roles -------------------------------------------+------------------------------- Reporter: haasn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- When trying to build acme-schoenfinkel (as an example), I came across an error like this: {{{ Control/Category/Schoenfinkel.hs:66:48: Could not coerce from ‘cat (cat b c, b) c’ to ‘cat (WrappedSchoenfinkel cat b c, b) c’ because ‘cat (cat b c, b) c’ and ‘cat (WrappedSchoenfinkel cat b c, b) c’ are different types. arising from the coercion of the method ‘app’ from type ‘forall b c. cat (cat b c, b) c’ to type ‘forall b c. WrappedSchoenfinkel cat (WrappedSchoenfinkel cat b c, b) c’ Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (ArrowApply (WrappedSchoenfinkel cat)) }}} It was not immediately clear to me as a user that this was caused due to it wanting GNT which was now being blocked by type roles (rightfully so, as this instance allows UnsafeCoerce!), and beyond that, what the specific rule that triggered this was. In this case the failure is due to ‘WrappedSchoenfinkel cat b c’ not being nominally equal to ‘cat b c’, in the type ‘(WrappedSchoenfinkel cat b c, b)’, which is required to be nominally equal to ‘(cat b c, b)’ because it's used as a parameter to the variable ‘cat’. Printing a location breakdown and context information similar to this to the user would help understanding and debugging roles a lot. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8984> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8749: Pattern synonyms crash GHCi
by GHC 18 Dec '14

18 Dec '14

#8749: Pattern synonyms crash GHCi ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ ghci -XPatternSynonyms > let pattern P x = x }}} causes a panic. I understand pattern synonyms are currently unsupported in GHCi, but we should give an error message, not a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8749> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906'
by GHC 18 Dec '14

18 Dec '14

#9426: ghci triggers 'ASSERT failed! file compiler/ghci/Linker.lhs, line 906' -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- Found by '''./validate --slow''': {{{ Unexpected failures: ghci/scripts ghci044 [bad stderr] (ghci) ghci/scripts ghci047 [bad stderr] (ghci) # run manially: $ LANG=C make fulltest stage=2 TEST="ghci044 ghci047" =====> ghci047(ghci) 87 of 4083 [0, 1, 0] cd ./ghci/scripts && HC='/home/st/fun/ghc/inplace/bin/ghc-stage2' HC_OPTS ='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' '/home/st/fun/ghc/inplace/bin/ghc-stage2' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history <ghci047.script >ghci047.run.stdout 2>ghci047.run.stderr Actual stderr output differs from expected: --- ./ghci/scripts/ghci047.stderr 2014-07-31 12:05:34.000000000 +0300 +++ ./ghci/scripts/ghci047.run.stderr 2014-08-08 16:58:01.000000000 +0300 @@ -1,16 +1,14 @@ +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906 +*** Exception: ASSERT failed! file compiler/ghci/Linker.lhs, line 906 -<interactive>:38:1: - Couldn't match type ‘HFalse’ with ‘HTrue’ - Expected type: HTrue - Actual type: Or HFalse HFalse - In the expression: f - In the expression: f $ Baz 'a' - In an equation for ‘it’: it = f $ Baz 'a' - -<interactive>:39:1: - Couldn't match type ‘HFalse’ with ‘HTrue’ - Expected type: HTrue - Actual type: Or HFalse HFalse - In the expression: f - In the expression: f $ Quz - In an equation for ‘it’: it = f $ Quz +<interactive>:36:1: Not in scope: ‘f’ + +<interactive>:37:1: Not in scope: ‘f’ + +<interactive>:38:1: Not in scope: ‘f’ + +<interactive>:39:1: Not in scope: ‘f’ + +<interactive>:40:1: Not in scope: ‘f’ + +<interactive>:41:1: Not in scope: ‘f’ Actual stdout output differs from expected: --- ./ghci/scripts/ghci047.stdout 2014-07-31 12:05:34.000000000 +0300 +++ ./ghci/scripts/ghci047.run.stdout 2014-08-08 16:58:01.000000000 +0300 @@ -1,4 +0,0 @@ -1 -1 -1 -1 *** unexpected failure for ghci047(ghci) }}} The trigger in '''compiler/ghci/Linker.lhs:906''': {{{#!hs linkSomeBCOs dflags toplevs_only ie ce_in ul_bcos = do let nms = map unlinkedBCOName ul_bcos hvals <- fixIO ( \ hvs -> let ce_out = extendClosureEnv ce_in (zipLazy nms hvs) in mapM (linkBCO dflags ie ce_out) ul_bcos ) let ce_all_additions = zip nms hvals ce_top_additions = filter (isExternalName.fst) ce_all_additions ce_additions = if toplevs_only then ce_top_additions else ce_all_additions ce_out = -- make sure we're not inserting duplicate names into the -- closure environment, which leads to trouble. {- 906 -} ASSERT(all (not . (`elemNameEnv` ce_in)) (map fst ce_additions)) extendClosureEnv ce_in ce_additions return (ce_out, hvals) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4