December 2014 - ghc-tickets

Re: [GHC] #8024: Dynamic linking not working on PowerPC Linux.
by GHC 12 Dec '14

12 Dec '14

#8024: Dynamic linking not working on PowerPC Linux. ----------------------------------------------+--------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: D560 | ----------------------------------------------+--------------------------- Changes (by slyfox): * status: infoneeded => patch * differential: => D560 Comment: The problem happened to be in code emitting prologs for basic block entries (also got fixed by https://phabricator.haskell.org/D560) Typically haskell function has single entry point (-fPIC -ddump-asm- native): {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... <HERE GOES ACTUAL CODE> ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} But sometimes runtime needs to return back into a middle of haskell function (try/catch primitives?) and prolog gets emitted at each such point using the same LCTOC offset: {{{ M.f_info: _ci4: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 1 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... <HERE GOES ACTUAL CODE> ... returns_here_later: ; PIC prolog bcl 20,31,1f 1: mflr %vI_nic ; REF 2 lwz %vI_nij, _nii-(1b)(%vI_nic) add %vI_nic, %vI_nic, %vI_nij ... ; offset to LCTOC from nearest '1:' .text .align 2 _nii: .long .LCTOC1-(1b)+0 }}} Here '_nii' contains offset to nearest '1:' label, not first one (as intended). It leads to miscomputation of LCTOC1 in function entry (around first '1:' which usually manifests in call to random location. It is fixed by using simpler prolog (similar to what modern gcc emits nowadays): {{{ bcl 20,31,1f 1: mflr %vI_ny4 addis %vI_ny4, %vI_ny4, .LCTOC1-(1b)@ha addi %vI_ny4, %vI_ny4, .LCTOC1-(1b)@l mr 30, %vI_ny4 }}} And it is safe to duplicate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8024#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints
by GHC 12 Dec '14

12 Dec '14

#2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: {{{ min :: Ord a => a -> a -> a }}} If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2256#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9583: Simplifier ticks exhausted while compiling Cabal HEAD
by GHC 11 Dec '14

11 Dec '14

#9583: Simplifier ticks exhausted while compiling Cabal HEAD -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Steps to reproduce: 1. Clone Cabal HEAD 2. `cabal configure --with-ghc=/path/to/ghc-head` 3. `dist/setup/setup build` Actual results: {{{ [ 8 of 78] Compiling Distribution.Text ( Distribution/Text.hs, dist/build/Distribution/Text.o ) [ 9 of 78] Compiling Distribution.Version ( Distribution/Version.hs, dist/build/Distribution/Version.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20140911 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone GHC.Word.$fNumWord8_$c+ To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 813720 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I know that it still fails with tick factor 4096; I haven't found a tick amount which makes it succeed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm
by GHC 11 Dec '14

11 Dec '14

#9566: T7891 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc-HEAD: {{{ $ make fulltest TEST="T7891" WAY=optasm cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7891.hs -O -fasm -fno-warn-incomplete-patterns >T7891.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the type ‘a_12 -> t_aiF -> t_aiF’ @ a_12 is out of scope *** Offending Program *** T7891.tf :: T7891.T [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] T7891.tf = GHC.Base.id `cast` (Sym T7891.NTCo:T[0] :: (forall t_ahj. t_ahj -> t_ahj) ~R# T7891.T) T7891.f :: forall t_ahw. t_ahw -> t_ahw [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] T7891.f = T7891.tf `cast` (T7891.NTCo:T[0] :: T7891.T ~R# (forall t_ahj. t_ahj -> t_ahj)) ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm
by GHC 11 Dec '14

11 Dec '14

#9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: tc124 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc-HEAD: {{{ $ make fulltest TEST="tc124" WAY=optasm =====> tc124(optasm) 3136 of 4101 [0, 0, 0] cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc124.hs -O -fasm -fno-warn-incomplete-patterns >tc124.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the type ‘a_12 -> a_aia -> a_aia’ @ a_12 is out of scope *** Offending Program *** Foo.g :: Foo.T -> Foo.T [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 40 30}] Foo.g = \ (t_ahr :: Foo.T) -> case t_ahr of _ [Occ=Dead] { Foo.T ds_dlB ds_dlC -> Foo.T ds_dlB (\ (@ a_ai4) (@ b_ai5) _ [Occ=Dead] (y_aht :: b_ai5) -> y_aht) } ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8240: Better error messages for type family constraints
by GHC 11 Dec '14

11 Dec '14

#8240: Better error messages for type family constraints ------------------------------------+------------------------------------- Reporter: simonpj | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider this constraint {{{ F Int ~ Bool -- Arising (say) on line 5 F Int ~ Char -- Arising (say) on line 10 }}} At the moment we'll combine the two to {{{ F Int ~ Bool -- Arising on line 5 Bool ~ Char -- Arising on line 10 }}} The second of these errors is "insoluble" and is reported first. But it's totally misleading: nowhere in the program did we directly need `Int~Char`. Another variant of this came up in Trac #8227. There we get the constraint {{{ Scalar (V a) ~ t0 Scalar (V a) ~ t0 -> t0 }}} which leads to {{{ Scalar (V a) ~ t0 -> t0 t0 ~ t0 -> t0 -- Occurs check }}} which gives the confusing error {{{ T8227.hs:16:44: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t0 Expected type: Scalar (V (t0 -> t0)) Actual type: Scalar (V a) }}} I think the solution is * Do not combine two Wanteds {{{ [W] F tys ~ t1 [W] F tys ~ t2 }}} unless t1 and t2 are both touchable unification variables. * Instead (perhaps) generate a Derived constraint {{{ [D] t1 ~ t2 }}} to express the fact that t1 and t2 had better end up equal. * To do this the inert set would need to contain many `CTyFunEq` constraints with the same LHS. I'm not very sure about this, and no time now, so I'm just making this ticket to record the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9569: Tuple constraints don't work right
by GHC 11 Dec '14

11 Dec '14

#9569: Tuple constraints don't work right -------------------------------------+------------------------------------- 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 this program: {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, KindSignatures, DataKinds, TypeFamilies #-} module Wrong where import GHC.Prim data Proxy (c :: Constraint) class Deferrable (c :: Constraint) where defer :: Proxy c -> (c => a) -> a deferPair :: (Deferrable c1, Deferrable c2) => Proxy (c1,c2) -> ((c1,c2) => a) -> a deferPair = undefined instance (Deferrable c1, Deferrable c2) => Deferrable (c1,c2) where -- defer p f = deferPair p f -- Succeeds defer = deferPair -- Fails }}} The first (commented-out) definition of `defer` in the instance declaration succeeds; but the second fails with an utterly bogus message {{{ ConstraintBug.hs:27:13: Could not deduce (c1 ~ (c1, c2)) from the context (Deferrable c1, Deferrable c2) }}} The reason is that when type-checking the method defintion we try to unify {{{ ((c1,c2) => a) ~ ((gamma1, gamma2) => alpha) }}} where * the LHS comes from instantiating the signature `(c => a)` (from the class decl) with `(c1,c2)/c` from the instance. * the RHS comes from instantiating the type of `deferPair` with fresh unification variables. The difficulty is that in the type of `deferPair`, the concrete syntax {{{ deferPair :: ...((c1,c2) => a)... }}} is really just syntactic sugar for {{{ deferPair :: ...(c1 => c2 => a)... }}} i.e. curried. But the function in the instantiated signature really has one constraint argument, a pair, not two. It's not clear how to fix this. It would actually be more consistent if {{{ f :: (Eq a, Show a) => blah }}} really did take a pair of dictionaries, rather than two curried dictionaries. But that would be a pretty big change, forced by a corner case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9404: tcInferRho muddies the waters
by GHC 11 Dec '14

11 Dec '14

#9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In trying to understand the algorithm implemented in !TcExpr, I've spent some time examining `tcInferRho`. I conjecture that this function is superfluous and should be removed, in favor of `tcInfer . tcExpr`. Some of these thoughts were first written up in [http://www.haskell.org/pipermail /ghc-devs/2014-July/005733.html this thread]. After a considerable amount of staring, I've actually found a misbehavior caused by the current implementation. `tcInferRho` calls `tcInfExpr`, which has only 3 special cases before calling `tcInfer . tcExpr`: for variables, parentheses, and application. I was first drawn into this problem because these three cases seem woefully insufficient for the problem at hand. I was surprised how such a paucity of cases could have survived without causing havoc, if indeed `tcInferRho` were necessary at all. For example, only normal (prefix) application is handled; infix application is missing. In looking at differences between `tcInferApp` (which is called from the application case of `tcInfExpr`) and `tcApp` (called from `tcExpr`), I saw that the former doesn't have a special case for `seq` while the latter does. And, indeed, this difference is exploitable. This compiles fine: {{{ foo _ = case () `seq` (# #) of (# #) -> () }}} This does not: {{{ foo _ = case seq () (# #) of (# #) -> () }}} which produces {{{ Scratch.hs:15:21: Kind incompatibility when matching types: b0 :: * (# #) :: # In the second argument of ‘seq’, namely ‘(##)’ In the expression: seq () (##) }}} Looking at the code, this behavior is expected, because the first version of the code calls into `tcInfer . tcExpr`, which special-cases `seq`, while the second is caught by `tcInferApp`, which doesn't have the special case. The above example shows that this isn't just a theoretical concern about code cleanup! This all leads to another question: Why special-case `seq` at all? !MkId tells me that {{{ seq :: forall (a :: *) (b :: *). a -> b -> b }}} Why isn't it {{{ seq :: forall (a :: *) (b :: OpenKind). a -> b -> b }}} With the second type, I would imagine that `seq` wouldn't need a special case in the type-checker. Is there something wrong with the second type for `seq`? I'll post more thoughts to this ticket as I continue to explore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies
by GHC 11 Dec '14

11 Dec '14

#9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have the following module {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, TypeFamilies #-} import GHC.Exts (Constraint) type family D (c :: Constraint) :: Constraint type instance D (Eq a) = Eq a -- checks f :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f g x = g x -- checks f' :: Eq b => (forall a. Eq a => f a -> Bool) -> f b -> Bool f' = f -- checks, so GHC seems to think that both types are interchangeable f'' :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f'' = f' -- checks test' y = f' (\ (Just x) -> x /= x) y -- fails test y = f (\ (Just x) -> x /= x) y -- fails too, unsurprisingly test'' y = f'' (\ (Just x) -> x /= x) y }}} The module checks with GHC-7.6.3, but fails in GHC-7.8.2 and GHC-7.9.20140430 with {{{ src/Test.hs:24:16: Couldn't match type ‘f’ with ‘Maybe’ ‘f’ is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:24:10-35 ‘f’ is a rigid type variable bound by the inferred type of test :: Eq b => f b -> Bool at src/Test.hs:24:1 Possible fix: add a type signature for ‘test’ Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:24:6) test :: f b -> Bool (bound at src/Test.hs:24:1) In the pattern: Just x In the first argument of ‘f’, namely ‘(\ (Just x) -> x /= x)’ In the expression: f (\ (Just x) -> x /= x) y src/Test.hs:27:20: Couldn't match type ‘f’ with ‘Maybe’ ‘f’ is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:27:12-39 ‘f’ is a rigid type variable bound by the inferred type of test'' :: Eq b => f b -> Bool at src/Test.hs:27:1 Possible fix: add a type signature for ‘test''’ Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:27:8) test'' :: f b -> Bool (bound at src/Test.hs:27:1) In the pattern: Just x In the first argument of ‘f''’, namely ‘(\ (Just x) -> x /= x)’ In the expression: f'' (\ (Just x) -> x /= x) y }}} I'd expect it to typecheck. At first, I thought this might be related in some way to #8985. That's why I tested with HEAD, but while #8985 seems indeed to be fixed, this is still a problem there. Also, while my simplified test case compiles with GHC-7.6.3, my original more complicated program does not, so there might be another report forthcoming if I manage to isolate the difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2986: :info printing instances often isn't wanted
by GHC 11 Dec '14

11 Dec '14

#2986: :info printing instances often isn't wanted -------------------------------------+------------------------------------- Reporter: Remi | Owner: Remi Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.10.1 Component: GHCi | Keywords: :info instances Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe put up a patch on Phab for review, if you think you are done? Don't forget tests, user manual... Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2986#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0