April 2015 - ghc-tickets

[GHC] #8391: FunDeps coverage condition check failure with PolyKinds
by GHC 15 Apr '15

15 Apr '15

#8391: FunDeps coverage condition check failure with PolyKinds ----------------------------+---------------------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #8356 | ----------------------------+---------------------------------------------- The following code: {{{ #!haskell {-# LANGUAGE FunctionalDependencies, FlexibleInstances, UndecidableInstances, TypeFamilies, PolyKinds #-} module FunDepsIssue where type Foo a = a class Foo a ~ b => Bar a b | a -> b instance Foo a ~ b => Bar a b }}} results in: {{{ Illegal instance declaration for ‛Bar k a b’ Multiple uses of this instance may be inconsistent with the functional dependencies of the class. In the instance declaration for ‛Bar a b’ }}} This appears to be a regression from 7.6.3, where it compiles OK. The same error occurs when the type synonym is replaced with a type family (which is the case I was originally interested in) or a type constructor like `Data.Proxy`, as long as it's poly-kinded it seems. So the following cases also fail to compile: {{{ #!haskell type family Foo (a :: k) :: * type family Foo (a :: *) :: k type family Foo (a :: k) :: k type family Foo (a :: k) :: k' }}} Looking through the source code, I think that the issue is that the coverage condition check doesn't close over kind variables, when it compares the vars on each side of the functional dependency. But `Foo a` has a hidden kind variable, so the l.h. varset `{a}` is insufficient to fix `b` using `Foo a ~ b`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux)
by GHC 14 Apr '15

14 Apr '15

#10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: | Owner: masterdezign | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Compiler | Operating System: Linux Keywords: strange | Type of failure: Runtime crash closure type | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling project with RTS options $ ghc --make -threaded Simul.hs -fforce-recomp -O2 and running it on Ubuntu 12.04 $ time ./Simul +RTS -N6 repeatedly received this message: Simul: internal error: evacuate: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 2131.46user 45.57system 6:13.95elapsed 582%CPU (0avgtext+0avgdata 185328maxresident)k 248inputs+0outputs (2major+11705minor)pagefaults 0swaps $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.3") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3") ,("Global Package DB","/usr/local/haskell/ghc-7.8.3-x86_64/lib/ghc-7.8.3/package.conf.d") ] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #3397: :step hangs when -fbreak-on-exception is set
by GHC 14 Apr '15

14 Apr '15

#3397: :step hangs when -fbreak-on-exception is set -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gelisam): * cc: hvr (added) * status: closed => new * version: 6.10.3 => 7.10.1-rc2 * resolution: worksforme => Comment: I have encountered this very old bug with GHC 7.10.0.20150123, here's a minimal test case: {{{#!hs mapLookup :: () -> () mapLookup = go where go () = () withDummyLookup :: IO a -> IO a withDummyLookup body = do mapLookup () `seq` return () body main :: IO () main = withDummyLookup (return ()) }}} To reproduce: {{{ $ ghci Example.hs *Main> :set -fbreak-on-exception *Main> :steplocal main Stopped at Example.hs:12:8-34 _result :: IO () = _ [Example.hs:12:8-34] *Main> :steplocal (hangs forever) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3397#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10233: Reexporting GHC.Exts does not export Constraint
by GHC 14 Apr '15

14 Apr '15

#10233: Reexporting GHC.Exts does not export Constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I expected the following code {{{ module T (module GHC.Exts) where import GHC.Exts (Constraint) }}} to reexport `Constraint`, but in fact `T` exports nothing at all. Explicitely exporting `Constraint` from `T` works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10233> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10195: GHC forgets constraints when matching on GADTs
by GHC 14 Apr '15

14 Apr '15

#10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here's a relatively short piece of code that doesn't compile: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GADTs, ConstraintKinds, KindSignatures, FlexibleInstances #-} module Foo where import GHC.Exts data Foo m zp r'q = Foo zp data Dict :: Constraint -> * where Dict :: a => Dict a type family BarFamily a b :: Bool class Bar m m' instance (BarFamily m m' ~ 'True) => Bar m m' magic :: (Bar m m') => c m zp -> Foo m zp (c m' zq) magic = error "" getDict :: a -> Dict (Num a) getDict _ = error "" fromScalar :: r -> c m r fromScalar = error "" foo :: (Bar m m') => c m zp -> Foo m zp (c m' zq) -> Foo m zp (c m' zq) foo b (Foo sc) = let scinv = fromScalar sc in case getDict scinv of Dict -> magic $ scinv * b }}} GHC complains that it {{{ cannot deduce (BarFamily m m' ~ 'True) arising from a use of `magic` }}} in the definition of `foo`. Of course this is silly: `magic` requires `Bar m m'`, which is supplied as a constraint to `foo`. So GHC is forgetting about the constraint on `foo` and instead trying to satisfy the generic instance of `Bar` which has the constraint `(BarFamily m m' ~ 'True)`. I've found no less than six different ways to poke this code to make it compile, and some of them seem to reveal dangerous/unexpected behavior. The following are all deltas from the original code above and result in compiling code. 1. Add `ScopedTypeVariables` and give `scinv` an explicit signature: {{{ let scinv = fromScalar sc :: c m z in ... }}} I'm not sure why this would make GHC suddenly realize that it already has the constraint `Bar m m'`, but it seems to. (What it definitely does *not* do is result in a `BarFamily m m' ~ 'True` constraint.) 2. Remove the instance for `Bar`. This seems highly suspicious: the presence (or lack thereof) of an instance changes how GHC resolves the constraint in `foo`. 3. Change the constraint on `foo` to `BarFamily m m' ~ 'True`. In this case, GHC does *not* forget the constraint on `foo` and successfully uses it to satisfy the instance of `Bar`. Why does GHC forget about `Bar m m'` but not `BarFamily m m' ~ 'True`? 4. Add the superclass constraint `BarFamily m m' ~ 'True` to class `Bar`. Adding this constraint either makes GHC find the `Bar m m'` constraint on `foo` or, even more bizarrely, GHC still forgets about `Bar m m'` but manages to get the superclass constraint from `Bar m m'` and uses it to satisfy the instance. 5. Add `PolyKinds`. Not sure why this would affect anything. 6. Change the signature of `fromScalar` to `r -> s`. Not sure why this would affect anything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10275: LLVM/cross-compilation fixes to be backported
by GHC 14 Apr '15

14 Apr '15

#10275: LLVM/cross-compilation fixes to be backported -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to have these fixes backported so that ghc-android will be able to build on 7.10.2 without having to duplicate patches that already exist in HEAD. The patches I needed are: - Phab:D597 - Phab:D683 - Phab:D745 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10274: foreign import ccall "rand" in System.IO fails on Android
by GHC 14 Apr '15

14 Apr '15

#10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Other Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On Android `rand` is a static inline function. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10232: versionedAppDir ignores projectVersion from DynFlags
by GHC 14 Apr '15

14 Apr '15

#10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- versionedAppDir uses the constant cProjectVersion rather than (projectVersion dflags). versionedAppDir was introduced after GHC 7.10 RC1 and I unfortunately didn't catch this before the release. This changes the location of the user package DB, which is now inconsistent between Cabal and GHCJS, making the user pkg db unusable when GHC has been compiled with 7.10.1 Symlinking the user package db directory is a workaround, but it's only a partial solution since multiple GHCJS versions on the same GHC will clash. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10148: Optimization causes repeated computation
by GHC 14 Apr '15

14 Apr '15

#10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The attached program, when compiled with `-O0`, calls `array_adjust` 6 times and hence prints 6 lines of trace output. However, with `-O1`, it prints 37 lines of trace output instead. Moreover, this number grows quadratically rather than linearly when I increase the value of `n`. `-fno-state-hack` did not help. I can reproduce the issue with both GHC 7.8.4 and 7.10.0.20150123. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10148> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10218: GHC creates incorrect code which throws <<loop>>
by GHC 14 Apr '15

14 Apr '15

#10218: GHC creates incorrect code which throws <<loop>> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- My co-worker and I have spent almost two weeks tracking down this bug. We have finally produced a reasonably small test case... please take a look: https://github.com/yongqli/ghctestcase Under certain circumstances GHC generates incorrect code which goes into <<loop>>. When you compile and run the project without profiling and with eager black-holing, it will throw <<loop>> and exit. If you compile either without eager black-holing or with profiling, it will run correctly. See setup.hs for further details. This bug can be delicate to trigger, inlining certain things will prevent it from occurring. However, we've encountered this in production, and it is much harder to work-around in an actual project. We've had to resort to inlining every function in the affected module, which slows down compilation considerably. We've found that this bug triggers on 7.10.1 and 7.8.4. The test case will only compile on 7.10.1. Please let me know if there are any questions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16