April 2017 - ghc-tickets

[GHC] #10227: Type checker cannot deduce type
by GHC 19 Apr '17

19 Apr '17

#10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | 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: | -------------------------------------+------------------------------------- When using closed type families the type checker does not use all the information that the closedness condition implies. In the following module the type checker fails to deduce the type for `f`. But lets start with `descrIn` since it has the same problem. The deduced type is `(D d Bool ~ Bool, D d Double ~ Bool, D d (Maybe String) ~ Bool) => Descr d`. But it is (to quote Simon PJ) plain as a pikestaff that `D d Double ~ Bool` can only hold if `d ~ In`, since there are only two equations and it cannot be the second. Similar reasoning can be used to deduce all the commented out type signatures. {{{#!hs {-# LANGUAGE RecordWildCards, TypeFamilies, DataKinds, NoMonomorphismRestriction, FlexibleContexts #-} module Main(main) where import Data.Maybe data InOut = In | Out type family D (d :: InOut) a where D 'In a = Bool D 'Out a = a data Descr d = Descr { abc :: D d Bool, def :: D d Double, ghi :: D d (Maybe String) } --descrIn :: Descr 'In descrIn = Descr { abc = False, def = True, ghi = True } --f :: Descr 'Out -> Double f Descr{..} = def + read (fromMaybe "0" ghi) --g :: Descr 'In -> Descr 'Out g d = Descr { abc = if abc d then True else False, def = if def d then 1234 else 0, ghi = if ghi d then Just "3008" else Nothing } main :: IO () main = do print $ f $ g descrIn }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13571: Injective type family syntax accepted without TypeFamilyDependencies
by GHC 19 Apr '17

19 Apr '17

#13571: Injective type family syntax accepted without TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program compiles fine although it names the result type variable, which is a piece of syntax that should only be available with `TypeFamilyDependencies` (injective type families): {{{#!haskell {-# LANGUAGE TypeFamilies #-} module Foo where type family F a = r where F a = a }}} If I say: {{{#!haskell type family F a = r | r -> a where F a = a }}} only then the definition is rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13571> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11511: Type family producing infinite type accepted as injective
by GHC 19 Apr '17

19 Apr '17

#11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A question came up during discussion at University of Wrocław: {{{#!hs type family F a = r | r -> a where F a = [F a] }}} Should this pass the injectivity check? Currently it does but I don't think this is correct. After all `F Bool` and `F Char` both reduce to the same infinite type `[[[...]]]`, which by definition of injectivity gives us `Char ~ Bool`. Is this dangerous in practice? It can cause reduction stack overflow (or an infinite loop if you disable that check) but I don't think this can be used to construct unsafe coerce. We'd have to unify two infinite types, which does not seem possible. This is not an implementation problem - this stays faithful to theory developed in injective type families paper. If others agree that this is indeed incorrect then I think the right solution here would be to drop equation (7) from our algorithm in the paper. For generalized injectivity we planned drop that equation anyway. Here's another reason for doing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 19 Apr '17

19 Apr '17

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13588: Simplify StgCase when all alternatives are the case binder
by GHC 19 Apr '17

19 Apr '17

#13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Nudged by rwbarton, simponpj writes in ticket:13536#comment:16: Yes. It's really {{{ case e of w { p1 -> w; ...; pn -> w } ===> e }}} (Core has a more general version involving strictness on x.) I don't know how much it happens in practice. It would not be hard to include this in StgCse though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13588> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13569: Optimise code-gen for field-updates of large products
by GHC 18 Apr '17

18 Apr '17

#13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's something we talked about last year which I wanted to look into but then got distracted (but I'm writing this one up now so it doesn't get lost again): Consider large field updates such as {{{#!hs module BigRec where data T = C { fld01 :: !Int , fld02 :: !Int , fld03 :: Int , fld04 :: Int , fld05 :: Int , fld06 :: Int , fld07 :: Int , fld08 :: Int , fld09 :: Int , fld10 :: Int , fld11 :: Int , fld12 :: Int , fld13 :: Int , fld14 :: Int , fld15 :: Int , fld16 :: Int , fld17 :: Int , fld18 :: Int , fld19 :: Int } inc01 x = x { fld01 = (fld01 x) + 1 } inc0102 x = x { fld01 = (fld01 x) + 1, fld02 = (fld02 x) + 1 } }}} These get translated into long chains of assignments, which in turn result in respectively long chains of register<->memory move instructions being generated by the NCG {{{#!c BigRec.inc0102_entry() // [R2] { [(c1em, block_c1em_info: const 0; const 31;), (c1ep, BigRec.inc0102_info: const 4294967301; const 0; const 15;)] } {offset c1ep: if ((Sp + -8) < SpLim) goto c1ez; else goto c1eA; c1ez: // nop R1 = BigRec.inc0102_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c1eA: I64[Sp - 8] = block_c1em_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c1em; else goto c1en; c1en: call (I64[R1])(R1) returns to c1em, args: 8, res: 8, upd: 8; c1em: Hp = Hp + 160; if (Hp > I64[BaseReg + 856]) goto c1eD; else goto c1eC; c1eD: I64[BaseReg + 904] = 160; // nop call stg_gc_unpt_r1(R1) returns to c1em, args: 8, res: 8, upd: 8; c1eC: _s15F::P64 = P64[R1 + 7]; _s15G::P64 = P64[R1 + 15]; _s15H::P64 = P64[R1 + 23]; _s15I::P64 = P64[R1 + 31]; _s15J::P64 = P64[R1 + 39]; _s15K::P64 = P64[R1 + 47]; _s15L::P64 = P64[R1 + 55]; _s15M::P64 = P64[R1 + 63]; _s15N::P64 = P64[R1 + 71]; _s15O::P64 = P64[R1 + 79]; _s15P::P64 = P64[R1 + 87]; _s15Q::P64 = P64[R1 + 95]; _s15R::P64 = P64[R1 + 103]; _s15S::P64 = P64[R1 + 111]; _s15T::P64 = P64[R1 + 119]; _s15U::P64 = P64[R1 + 127]; _s15V::P64 = P64[R1 + 135]; _s15X::I64 = I64[R1 + 151] + 1; _s15W::I64 = I64[R1 + 143] + 1; I64[Hp - 152] = BigRec.C_con_info; P64[Hp - 144] = _s15F::P64; P64[Hp - 136] = _s15G::P64; P64[Hp - 128] = _s15H::P64; P64[Hp - 120] = _s15I::P64; P64[Hp - 112] = _s15J::P64; P64[Hp - 104] = _s15K::P64; P64[Hp - 96] = _s15L::P64; P64[Hp - 88] = _s15M::P64; P64[Hp - 80] = _s15N::P64; P64[Hp - 72] = _s15O::P64; P64[Hp - 64] = _s15P::P64; P64[Hp - 56] = _s15Q::P64; P64[Hp - 48] = _s15R::P64; P64[Hp - 40] = _s15S::P64; P64[Hp - 32] = _s15T::P64; P64[Hp - 24] = _s15U::P64; P64[Hp - 16] = _s15V::P64; I64[Hp - 8] = _s15W::I64; I64[Hp] = _s15X::I64; R1 = Hp - 151; }}} This happens in a few places inside GHC's source-tree (where we have large-ish products, such as DynFlags where we update single fields), which is where I noticed this while looking at generated ASM output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1
by GHC 18 Apr '17

18 Apr '17

#13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This currently causes the `vector` test suite to loop forever (see [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]). I've reproduced this with GHC 8.2.1 and HEAD. Unfortunately, it's not easy to isolate down to a file with no dependencies, so for now this requires `vector` and `QuickCheck` to reproduce. First, install them: {{{ $ cabal install vector QuickCheck --allow-newer -w /opt/ghc/8.2.1/bin/ghc }}} Then take this file: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module Main (main) where import qualified Data.Vector.Generic as V import qualified Data.Vector.Unboxed as DVU import Test.QuickCheck import Text.Show.Functions () main :: IO () main = do verboseCheck ((\f (i, b) v -> V.foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) ( DVU.toList v)) :: ((Int, Bool) -> (Int, Bool) -> (Int, Bool)) -> (Int, Bool) -> DVU.Vector (Int, Bool) -> Bool) instance (Arbitrary a, DVU.Unbox a) => Arbitrary (DVU.Vector a) where arbitrary = fmap DVU.fromList arbitrary class TestData a where type Model a unmodel :: Model a -> a instance TestData Bool where type Model Bool = Bool unmodel = id instance TestData Int where type Model Int = Int unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} Then compile it with `/opt/ghc/8.2.1/bin/ghc -O2 Main.hs` (the `-O2` part is important). Observe that running it never terminates. However, the same program //does// terminate when compiled with 8.0.2! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #13581: UNPACK should allow recursion that obviously terminates
by GHC 18 Apr '17

18 Apr '17

#13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- I want to do this: {{{ {-# LANGUAGE TypeFamilies MagicHash KindSignatures #-} data Peano = Zero | Succ Peano data family BigWord (n :: Peano) data instance BigWord Zero = MachineWord# Word# data instance BigWord (Succ n) = BigWord {-# UNPACK #-}(BigWord n) {-# UNPACK #-}(BigWord n) }}} However, the compiler tells me that it is ignoring the UNPACKs, and the only reason I can see is that they are apparently recursive. This exact type of recursion is handled just fine in instance declarations because the recursive instance has fewer type constructors than the head; can't UNPACK do the same thing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE
by GHC 18 Apr '17

18 Apr '17

#12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program allocates much more memory ("bytes allocated in the heap") in its current form than with INLINE replaced by NOINLINE, as in the comment. That may be normal, but virtually every feature of this example is needed to trigger the behaviour and so I have no clear idea which language feature is responsible and should be avoided and, consequently, how to optimize my much more complex codebase (in which INLINES of once used functions tend to help and sometimes significantly so). As a comment to this ticket I will post another example, where the difference in allocation is pumped to a factor of 2000, as a proof that the issue is serious. {{{ {-# LANGUAGE RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE and observe lower alloc dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (_, x) = pI `quotRem` z in P x m = IM.lookup (fromEnum p0) IM.empty b = IM.member (fromEnum p1) IM.empty in m == Just 'c' `seq` b `seq` () {-# NOINLINE l #-} l = [0..10000000] mapVT :: forall s. () -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l return $! runST (mapVT ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13528: Unqualified export of constructors
by GHC 18 Apr '17

18 Apr '17

#13528: Unqualified export of constructors -------------------------------------+------------------------------------- Reporter: dmendler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Unqualified exports of constructors doesn't work anymore in 8.2.1-rc1. It worked before in 8.0. Is this intended or a regression? {{{ module Test ( GHC.Exts.IsList( Item , fromList , toList ) , Data.Bool.Bool(True, False) ) where import qualified GHC.Exts import qualified Data.Bool }}} The error: {{{ • Not in scope: data constructor ‘False’ Perhaps you meant ‘Prelude.False’ (imported from Prelude) • In the export: Data.Bool.Bool(False, True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7