January 2017 - ghc-tickets

[GHC] #12885: "too many iterations" causes constraint solving issue.
by GHC 25 Feb '17

25 Feb '17

#12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following file compiled fine with ghc-7.10, but fails in ghc-8.0.2-rc1 (as well as ghc-8.0.1). This is a simplified version of a compilation issue with ghc-8 and https://github.com/tensorflow/haskell. It seems similar to #12175, but even though that was fixed in ghc-8.0.2-rc1, the below code still doesn't compile. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintTest where import Data.Int import Data.Word import GHC.Exts (Constraint) import Lens.Family2 ((.~), (&), Lens') import Lens.Family2.Unchecked (lens) class MyType a where instance MyType Int8 instance MyType Int16 instance MyType Int32 instance MyType Int64 instance MyType Word8 instance MyType Word16 instance MyType Word32 -- Require every element in the list to be an instance of 'MyType'. type family MyTypes (as :: [*]) :: Constraint where MyTypes '[] = () MyTypes (a ': as) = (MyType a, MyTypes as) data Foo = Foo { fooInt :: Int } class Attr a where attr :: Lens' Foo a instance Attr Int where attr = lens fooInt (\f n -> f { fooInt = n }) test :: MyTypes '[Int8,Int16,Int32,Int64,Word8,Word16,Word32] => Foo test = attr .~ (3 :: Int) $ Foo 0 }}} Compilation error: {{{ tensorflow/tests/ConstraintTest.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [W] hole{a282} :: b_a25A ~ Int (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Some ways to change the test to make the compilation succeed: - Pass "-fconstraint-solver-iterations=0" to ghc. - Shorten the type-level list in the constraint of `test`. - Replace `Lens.Family2` with `Lens.Micro` from the `microlens` package. I think this is because `Lens.Family2`'s version of (.~) is higher-order than `Lens.Micro`: https://hackage.haskell.org/package/lens-family-1.2.1/docs/Lens- Family2.html#v:.-126- https://hackage.haskell.org/package/microlens-0.4.7.0/docs/Lens- Micro.html#v:.-126- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS
by GHC 25 Feb '17

25 Feb '17

#12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an annoyance I discovered when working with the [https://github.com/rrnewton/haskell- lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops atomic-primops] package on Windows. Here is a simplified test case: {{{#!hs module Main (main) where foreign import ccall unsafe "store_load_barrier" storeLoadBarrier :: IO () main :: IO () main = do putStrLn "1" storeLoadBarrier putStrLn "2" }}} Compiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [https://github.com/rrnewton/haskell-lockfree/pull/38 this], the issue is likely much older than 8.0.1). {{{ $ runghc Bug.hs Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: store_load_barrier This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} To work around this issue, `atomic-primops` currently links against [https://github.com/rrnewton/haskell- lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic- primops/cbits/RtsDup.c#L52-L69 a separate C file] that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM
by GHC 25 Feb '17

25 Feb '17

#12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 example is slimmed down unit test of Annotations-0.2.1 hackage package. If we try to compile Bug.hs with -O0 it compiles quickly. Trying it with -O1 makes GHC-8.0.1 takes a minute to finish. {{{#!hs -- Bug1.hs: {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} {- # OPTIONS_GHC -O1 #-} module Bug () where import Prelude (Eq) data ExprF rT = ExprF rT rT deriving Eq newtype Expr = Expr (Fix ExprF) deriving Eq newtype Fix fT = In (fT (Fix fT)) deriving instance Eq (f (Fix f)) => Eq (Fix f) }}} {{{ $ time ghc-8.0.1 -c -O0 Bug1.hs -fforce-recomp real 0m0.611s user 0m0.549s sys 0m0.053s $ time ghc-8.0.1 -c -O1 Bug1.hs -fforce-recomp real 1m2.199s user 1m1.676s sys 0m0.465s }}} 7.10.2 for comparison is very quick in both O0/O1: {{{ $ time ghc-7.10.2 -c -O0 Bug1.hs -fforce-recomp real 0m0.220s user 0m0.183s sys 0m0.036s $ time ghc-7.10.2 -c -O1 Bug1.hs -fforce-recomp real 0m0.237s user 0m0.213s sys 0m0.023s }}} The real ExprF datatype uses more constructors and instances: {{{ data ExprF rT = Add rT rT | Sub rT rT | Mul rT rT | Div rT rT | Num Int deriving (Eq, Show) }}} That requires a lot of time and space to finish (Bug2.hs in attach). I've stopped it after 5 minutes (took ~8GB RAM). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12234> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #11731: Demand analysis: Thunk wrongly determined single-entry
by GHC 25 Feb '17

25 Feb '17

#11731: Demand analysis: Thunk wrongly determined single-entry -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- While working on #10613, I looked a bit more closely at the ticky numbers of single-entry thunks. In all of nofib, I found exactly one fishy result: A thunk, marked as single entry, but entered multiple times, in gameteb. I’ll write a preliminary analysis in the comments and either found a bug or a misunderstanding on my side. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53

[GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer
by GHC 25 Feb '17

25 Feb '17

#12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've just taken over an existing haskell package and in the process of getting it to work with ghc 8.0 discovered that when compiling one file ghc tires to use all my ram. It basically ends up using 40% of 16 Gig before being killed by the OOM (out-of-memory) killer. The project is at: https://github.com/erikd/conduit-find.git The problem can be reproduced by: {{{ git clone https://github.com/erikd/conduit-find.git cd conduit-find git checkout test/ghc-8.0 cabal sandbox init cabal install --dependencies-only cabal build }}} which on two of my machines fails building the `Data.Cond` module. This is regression, because this code compiles fine with ghc-7.10.3 and ghc-7.8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O
by GHC 25 Feb '17

25 Feb '17

#12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc version: 41ec722d71 with assertion that fails in https://ghc.haskell.org/trac/ghc/ticket/12926 commented out {{{#!hs {-# LANGUAGE TypeFamilies #-} module Numeric.Polynomial.Log () where class AdditiveGroup v where (^+^) :: v -> v -> v negateV :: v -> v (^-^) :: v -> v -> v v ^-^ v' = v ^+^ negateV v' class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v data Poly1 a = Poly1 a a data IntOfLog poly a = IntOfLog !a !(poly a) instance Num a => AdditiveGroup (Poly1 a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} Poly1 a b ^+^ Poly1 a' b' = Poly1 (a + a') (b + b') negateV (Poly1 a b) = Poly1 (negate a) (negate b) instance (AdditiveGroup (poly a), Num a) => AdditiveGroup (IntOfLog poly a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} IntOfLog k p ^+^ IntOfLog k' p' = IntOfLog (k + k') (p ^+^ p') negateV (IntOfLog k p) = IntOfLog (negate k) (negateV p) {-# SPECIALISE instance Num a => AdditiveGroup (IntOfLog Poly1 a) #-} instance (VectorSpace (poly a), Scalar (poly a) ~ a, Num a) => VectorSpace (IntOfLog poly a) where type Scalar (IntOfLog poly a) = a s *^ IntOfLog k p = IntOfLog (s * k) (s *^ p) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): ASSERT failed! $dAdditiveGroup_aIU Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12776: Panic Simplifier ticks exhausted since ghc 8
by GHC 25 Feb '17

25 Feb '17

#12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I'm getting a panic! in GHC 8.0.1 and in 8.1.20161028 {{{ sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Main.hs -O2 [1 of 2] Compiling Factorize ( Factorize.hs, Factorize.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161028 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $slast_s_s1IU 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: 18241 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached is some code which I tried to make as small as possible (it therefore does not make sense, but it reproduces the panic). The panic! only occurs with -O2 (I need the -O2 switch to optimise the automatically generated Haskell code). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12680: Permit type equality instances in signatures
by GHC 24 Feb '17

24 Feb '17

#12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- David Christiansen requested this, and I want to record it so I don't forget. What he wants to be able to do is say things like this in signatures: {{{ signature A where data T data S type family F a instance T ~ S instance F Int ~ S }}} This is currently rejected by GHC because you are not allowed to define instances of type equality. But really all this is saying is that the type equality must hold when we eventually implement the module; easy to check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12971: gcc not finding default temporary directory
by GHC 24 Feb '17

24 Feb '17

#12971: gcc not finding default temporary directory -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Hello, I've been trying to get the ghc to compile a .hs file to binary. I get an error that seems to be caused during the C compilation phase from the special character ä in my user directory. When compiling I get this: {{{ C:\Users\Erik Präntare>ghc C:\code\Haskell\test.hs Linking C:\code\Haskell\test.exe ... realgcc.exe: error: C:\Users\Erik Pr├ñntare\AppData\Local\Temp\ghc28912_0\ghc_1. c: No such file or directory realgcc.exe: fatal error: no input files compilation terminated. `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) }}} Notice how it says Pr├ñntare instead of Präntare. The UTF-8 encoding for ä is 0xC3 0xA4 which, surprise surprise, corresponds to ├ñ in ASCII. Now, I managed to get around this by changing the tmpdir to my actual temporary directory, but as a new user of ghc it was very troublesome to find a solution. Maybe consider changing the default tmpdir, at least if special characters are encountered? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13196: Document AMP as a deviation from Haskell 2010
by GHC 24 Feb '17

24 Feb '17

#13196: Document AMP as a deviation from Haskell 2010 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: AMP | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Applicative` class is not in Haskell 2010, and is certainly not a superclass of `Monad` there. This must be documented as a deviation in the user's guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6