May 2016 - ghc-tickets

[GHC] #12116: No easy way to add cost-centre to top-levels
by GHC 27 Aug '16

27 Aug '16

#12116: No easy way to add cost-centre to top-levels -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- As far as I can see from the user manual (I also tried placing some `SCC`s), there's no way to easily add cost-centres to top-level definitions. We can do things like: {{{ f x y z = ... => f = {-# SCC f #-} \x y z -> ... }}} but it becomes too much work once we have "equations" style definitions like {{{ head [] = {-# SCC head #-} Nothing head (x : _) = {-# SCC head #-} Just x }}} Also, `where` clauses work differently after the transformations. Example: {{{ f x y z = ... where <can use x and y here> => f = {-# SCC f #-} \x y z -> ... where <can't use x and y here> }}} So it gets annoying real quick. It'd be really great if we could just add `{-# SCC ... #-}` just like `{-# INLINE ... #-}` pragmas. Any ideas/opinions? Looking at the code, it seems like `-fprof-auto` and similar flags are adding ticks to `FunBind.fun_tick`. We could do the same with this new `SCC` pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10547: feature request: expanding type synonyms in error messages
by GHC 26 Aug '16

26 Aug '16

#10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type errors sometimes becoming confusing because of synonyms, for example, expected type and found type sometimes use different synonyms or sometimes only one of them use a synonym etc. We discussed this in the mailing list: https://mail.haskell.org/pipermail /ghc-devs/2015-June/009247.html And also moved it to the Wiki to collect examples: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal I'm currently working on a patch, I made some progress and I'll hopefully submit something for reviews in a couple of days. This ticket is for further discussions and keep track of the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #12125: Field accessors unnecessarily kept alive
by GHC 26 Aug '16

26 Aug '16

#12125: Field accessors unnecessarily kept alive -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 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): Phab:D2270 | Wiki Page: -------------------------------------+------------------------------------- Suppose you have a record with some non-exported field accessors, like so: {{{#!haskell module Lib (Rec) where data Rec = Rec { f1 :: Int , f2 :: Int , f3 :: Int , f4 :: Int , f5 :: Int } }}} Code for fields `f1`, `f2` ... are redundantly generated, optimized etc. and they made it to the object file, causing wasted compile times and bloated object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12125> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11442: Segfault when showing (undefined :: Type)
by GHC 26 Aug '16

26 Aug '16

#11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This [https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 comment] made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`: https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 {{{#!hs {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #- import Data.Kind (Type) instance Show Type where show _ = "..." main = print (undefined :: Type) }}} running gives: {{{ $ runghc --version runghc 8.1.20160113 $ runghc -ignore-dot-ghci Segfault.hs Segmentation fault (core dumped) }}} Verbose log attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1
by GHC 25 Aug '16

25 Aug '16

#11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test<n>.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test<n>.hs` If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12077: T8761 (Make pattern synonyms work with Template Haskell) is failing on Travis
by GHC 25 Aug '16

25 Aug '16

#12077: T8761 (Make pattern synonyms work with Template Haskell) is failing on Travis -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8761 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Note that Travis uses `DYNAMIC_GHC_PROGRAMS=NO`. First failure: https://travis-ci.org/ghc/ghc/builds/129738012 {{{ Actual stderr output differs from expected: --- ./th/T8761.stderr.normalised 2016-05-12 15:08:16.512921981 +0000 +++ ./th/T8761.comp.stderr.normalised 2016-05-12 15:08:16.512921981 +0000 @@ -1,7 +1,3 @@ -pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) -pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) -pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where - Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) T8761.hs:(15,1)-(38,13): Splicing declarations do { [qx1, qy1, qz1] <- mapM (/ i -> newName $ "x" ++ show i) [1, 2, 3]; @@ -123,30 +119,6 @@ pattern Pup x <- MkUnivProv x pattern Puep :: forall a. forall b. Show b => a -> b -> (ExProv, a) pattern Puep x y <- (MkExProv y, x) -pattern T8761.P :: GHC.Types.Bool -pattern T8761.Pe :: () => forall (a0_0 :: *) . a0_0 -> T8761.Ex -pattern T8761.Pu :: forall (a0_0 :: *) . a0_0 -> a0_0 -pattern T8761.Pue :: forall (a0_0 :: *) . () => forall (b0_1 :: *) . - a0_0 -> b0_1 -> (a0_0, T8761.Ex) -pattern T8761.Pur :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - a0_0 -> [a0_0] -pattern T8761.Purp :: forall (a0_0 :: *) (b0_1 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - GHC.Show.Show b0_1 => a0_0 -> b0_1 -> ([a0_0], T8761.UnivProv b0_1) -pattern T8761.Pure :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - forall (b0_1 :: *) . a0_0 -> b0_1 -> ([a0_0], T8761.Ex) -pattern T8761.Purep :: forall (a0_0 :: *) . (GHC.Num.Num a0_0, - GHC.Classes.Eq a0_0) => - forall (b0_1 :: *) . GHC.Show.Show b0_1 => - a0_0 -> b0_1 -> ([a0_0], T8761.ExProv) -pattern T8761.Pep :: () => forall (a0_0 :: *) . GHC.Show.Show a0_0 => - a0_0 -> T8761.ExProv -pattern T8761.Pup :: forall (a0_0 :: *) . () => GHC.Show.Show a0_0 => - a0_0 -> T8761.UnivProv a0_0 -pattern T8761.Puep :: forall (a0_0 :: *) . () => forall (b0_1 :: *) . GHC.Show.Show b0_1 => - a0_0 -> b0_1 -> (T8761.ExProv, a0_0) T8761.hs:(107,1)-(111,25): Splicing declarations do { infos <- mapM reify *** unexpected failure for T8761(normal) }}} @bollmann added the test in c079de3c43704ea88f592e441389e520313e30ad. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception
by GHC 25 Aug '16

25 Aug '16

#12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime | Version: 8.0.1-rc2 System | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run https://ghc.haskell.org/trac/ghc/ticket/1012#comment:5 with `ghc-8.0 --make ModuleB.hs -j0 -fforce-recomp` (the `-j0` is important) I get a `Floating point exception (core dumped)`. When I run under GDB, I get: {{{ (gdb) r Starting program: /srv/code/ghc-8.0.0.20160204/usr/lib/ghc-8.0.0.20160204/bin/ghc -B/home/ezyang/Dev/ghc-8.0.0.20160204/usr/lib/ghc-8.0.0.20160204 --make ModuleB.hs -j0 -fforce-recomp [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffecd7f700 (LWP 28877)] [New Thread 0x7fffe7fff700 (LWP 28878)] [New Thread 0x7fffe77fe700 (LWP 28879)] [1 of 4] Compiling ModuleA[boot] ( ModuleA.hs-boot, ModuleA.o-boot ) [2 of 4] Compiling ModuleC ( ModuleC.hs, ModuleC.o ) [3 of 4] Compiling ModuleA ( ModuleA.hs, ModuleA.o ) [4 of 4] Compiling ModuleB ( ModuleB.hs, ModuleB.o ) Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 0x7fffecd7f700 (LWP 28877)] schedule (initialCapability=<optimized out>, task=task@entry=0x7b6310) at rts/Schedule.c:373 373 rts/Schedule.c: No such file or directory. (gdb) bt #0 schedule (initialCapability=<optimized out>, task=task@entry=0x7b6310) at rts/Schedule.c:373 #1 0x00007fffed65018c in scheduleWorker (cap=<optimized out>, task=0x7b6310) at rts/Schedule.c:2378 #2 0x00007ffff738a6aa in start_thread (arg=0x7fffecd7f700) at pthread_create.c:333 #3 0x00007fffed14fe9d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 }}} I once got a different error running this: {{{ warning: Corrupted shared library list: 0x7e1ee0 != 0x7ffff7ffd9d8 }}} Looking at the code which is a `capabilities[cap->no % enabled_capabilities]`, I guess this is just something goofy, like GHC not rejecting `-j0` and then however we're setting the capabilities not checking this case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12128: ghci cause panic on 8.0.1
by GHC 25 Aug '16

25 Aug '16

#12128: ghci cause panic on 8.0.1 -------------------------------------+------------------------------------- Reporter: zxtx | 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 following code panics when called with ghci: {{{#!hs module Foo where import GHC.TypeLits (Symbol) import Unsafe.Coerce instance Read Symbol where readsPrec = unsafeCoerce (readsPrec :: Int -> ReadS String) data Bar = TyCon !Symbol deriving (Read) }}} {{{ % ghci foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/zv/.ghc/ghci.conf [1 of 1] Compiling Foo ( foo.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): atomPrimRep case a1_s2AG of _ [Occ=Dead] { } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11632: Data.Char repeated readLitChar barfs on output from show "ó1"
by GHC 25 Aug '16

25 Aug '16

#11632: Data.Char repeated readLitChar barfs on output from show "ó1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- "ó1" is "\243\&1" and when shown that's "\"\\243\\&1\"" {{{#!hs readLitChar "\"\\243\\&1\"" = [("\"", "\243\\&1")] readLitChar "\243\\&1" = [("\243", "\\&1")] --should have consumed "\\&" readLitChar "\\&1" = [] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11632> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12067: warn-unused-imports does not detect coersions
by GHC 25 Aug '16

25 Aug '16

#12067: warn-unused-imports does not detect coersions -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using `coerce`, GHC can erroneously warn that imports are unnecessary. For example: Foo.hs {{{ module Foo (MT(..), M) where import Control.Monad.Identity newtype MT m b = MT (m b) type M b = MT Identity b }}} Main.hs {{{ import Control.Monad.Identity import Data.Coerce import Foo foo :: M [a] -> MT [] a foo = coerce }}} GHC (with `-fwarn-unused-imports`) warns {{{ Main.hs:1:1: Warning: The import of ‘Control.Monad.Identity’ is redundant except perhaps to import instances from ‘Control.Monad.Identity’ To import instances alone, use: import Control.Monad.Identity() }}} But this is incorrect: we need the constructor `Identity` to be in scope in order for the coercion to succeed. Thus the import is not redundant, nor is it needed to import instances. In particular, the two implied suggestions 1. remove the import altogether 2. change the import to `import Control.Monad.Identity` both (correctly) result in compile errors. At a minimum, the warning message should be updated to include this possibility, but it would be even better if GHC could detect this and not throw a warning at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6