July 2016 - ghc-tickets

[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] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages
by GHC 25 Aug '16

25 Aug '16

#12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | 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 snippet (using the [https://hackage.haskell.org/package /ref-tf ref-tf library]) is well-typed, and GHC is fine with it: {{{#!hs import Control.Monad -- comment this out to cause error import Control.Monad.Ref main :: IO () main = newRef (pure ()) >>= join . readRef }}} However, if one comments out the first line, then GHC treats `join` as a typed hole due to #10569, but fails to infer its type, causing errors: {{{ test.hs:10:8-23: error: … • Couldn't match type ‘Ref m0’ with ‘GHC.IORef.IORef’ ... test.hs:10:29-32: error: … Variable not in scope: join :: m0 (f0 ()) -> IO () }}} By default the not-in-scope error is reported, but if `-fdefer-typed- holes` is in effect, only the type error is reported leaving the user (at least me) puzzled. Not-in-scope errors should ''always'' be reported. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[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] #12419: Scheduling bug with forkOS + MVar
by GHC 25 Aug '16

25 Aug '16

#12419: Scheduling bug with forkOS + MVar -----------------------------------------+--------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: forkOS; scheduler | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I have noticed a weird scheduling behavior when performing some experiments with the '''fasta''' benchmark [1] from The Computer Language Benchmarks Game. When I switch `forkIO` by `forkOS` the scheduler stops to assign work for some capabilities, and they stay idle for the whole execution of the program. ThreadScope view using forkIO: https://s31.postimg.org/r3mclspe3/fork_IO_N8_ghc8.png ThreadScope view using forkOS: https://s31.postimg.org/p9n265fff/fork_OS_N8_ghc8.png I was able to reproduce this behavior in both '''GHC 7.10.2''' and '''GHC 8.0.2'''. I was also able to reproduce it on two different machines running Ubuntu Server 14.04.3 LTS (kernel 3.19.0-25): - 2x10-core Intel Xeon E5-2660 v2 processors (Ivy Bridge), 2.20 GHz, with 256GB of DDR 1600MHz - 4-core Intel i7-3770 (IvyBridge) with 8 GB of DDR 1600MHz Source code + .eventlog files: https://dl.dropboxusercontent.com/u/5798150 /fasta-bug.zip [1] http://benchmarksgame.alioth.debian.org/u64q/program.php?test=fasta&lang=gh… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12208: double free or corruption (TEST=T5644 WAY=threaded1)
by GHC 25 Aug '16

25 Aug '16

#12208: double free or corruption (TEST=T5644 WAY=threaded1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Runtime | Version: 8.1 System | 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: -------------------------------------+------------------------------------- {{{ $ make test TEST=T5644 WAY=threaded1 ... =====> T5644(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T5644/T5644.run" && "/opt/ghc/head/bin/ghchead" --make -o T5644 heap-overflow.hs -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fno-ghci-history -threaded -debug -O > T5644.comp.stderr 2>&1 cd "./rts/T5644/T5644.run" && ./T5644 +RTS -M20m -RTS </dev/null > T5644.run.stdout 2> T5644.run.stderr *** Error in `./T5644': double free or corruption (fasttop): 0x00007f1e34000910 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7f1e495b7725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7f1e495bff4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f1e495c3abc] ./T5644[0x48d2dd] ./T5644[0x492d4b] ./T5644[0x490ffe] ./T5644[0x493ca7] ./T5644[0x48cde1] /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f1e499106fa] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f1e49646b5d] ======= Memory map: ======== 00400000-00518000 r-xp 00000000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 00718000-0071b000 r--p 00118000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 0071b000-00727000 rw-p 0011b000 b3:01 1458905 /home/thomas/ghc-devel2/testsuite/tests/rts/T5644/T5644.run/T5644 00727000-0072a000 rw-p 00000000 00:00 0 026cd000-0270f000 rw-p 00000000 00:00 0 [heap] 200000000-200200000 rw-p 00000000 00:00 0 200200000-201400000 ---p 00000000 00:00 0 201400000-201600000 rw-p 00000000 00:00 0 201600000-10200100000 ---p 00000000 00:00 0 7f1e34000000-7f1e34021000 rw-p 00000000 00:00 0 7f1e34021000-7f1e38000000 ---p 00000000 00:00 0 7f1e38000000-7f1e38021000 rw-p 00000000 00:00 0 7f1e38021000-7f1e3c000000 ---p 00000000 00:00 0 7f1e3c000000-7f1e3c021000 rw-p 00000000 00:00 0 7f1e3c021000-7f1e40000000 ---p 00000000 00:00 0 7f1e42ffe000-7f1e42fff000 ---p 00000000 00:00 0 7f1e42fff000-7f1e437ff000 rw-p 00000000 00:00 0 [stack:5323] 7f1e437ff000-7f1e43800000 ---p 00000000 00:00 0 7f1e43800000-7f1e44000000 rw-p 00000000 00:00 0 [stack:5322] 7f1e44000000-7f1e44021000 rw-p 00000000 00:00 0 7f1e44021000-7f1e48000000 ---p 00000000 00:00 0 7f1e48328000-7f1e4833e000 r-xp 00000000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4833e000-7f1e4853d000 ---p 00016000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4853d000-7f1e4853e000 rw-p 00015000 b3:01 920599 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f1e4853e000-7f1e4853f000 ---p 00000000 00:00 0 7f1e4853f000-7f1e48d3f000 rw-p 00000000 00:00 0 [stack:5321] 7f1e48d3f000-7f1e48d40000 ---p 00000000 00:00 0 7f1e48d40000-7f1e49540000 rw-p 00000000 00:00 0 [stack:5320] 7f1e49540000-7f1e49700000 r-xp 00000000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49700000-7f1e498ff000 ---p 001c0000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e498ff000-7f1e49903000 r--p 001bf000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49903000-7f1e49905000 rw-p 001c3000 b3:01 923095 /lib/x86_64-linux-gnu/libc-2.23.so 7f1e49905000-7f1e49909000 rw-p 00000000 00:00 0 7f1e49909000-7f1e49921000 r-xp 00000000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49921000-7f1e49b20000 ---p 00018000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b20000-7f1e49b21000 r--p 00017000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b21000-7f1e49b22000 rw-p 00018000 b3:01 923093 /lib/x86_64-linux-gnu/libpthread-2.23.so 7f1e49b22000-7f1e49b26000 rw-p 00000000 00:00 0 7f1e49b26000-7f1e49b29000 r-xp 00000000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49b29000-7f1e49d28000 ---p 00003000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d28000-7f1e49d29000 r--p 00002000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d29000-7f1e49d2a000 rw-p 00003000 b3:01 923097 /lib/x86_64-linux-gnu/libdl-2.23.so 7f1e49d2a000-7f1e49d31000 r-xp 00000000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49d31000-7f1e49f30000 ---p 00007000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f30000-7f1e49f31000 r--p 00006000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f31000-7f1e49f32000 rw-p 00007000 b3:01 923085 /lib/x86_64-linux-gnu/librt-2.23.so 7f1e49f32000-7f1e4a03a000 r-xp 00000000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a03a000-7f1e4a239000 ---p 00108000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a239000-7f1e4a23a000 r--p 00107000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a23a000-7f1e4a23b000 rw-p 00108000 b3:01 922754 /lib/x86_64-linux-gnu/libm-2.23.so 7f1e4a23b000-7f1e4a2ba000 r-xp 00000000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a2ba000-7f1e4a4b9000 ---p 0007f000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4b9000-7f1e4a4ba000 r--p 0007e000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4ba000-7f1e4a4bb000 rw-p 0007f000 b3:01 920765 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0 7f1e4a4bb000-7f1e4a4e1000 r-xp 00000000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a521000-7f1e4a6b9000 r--p 00000000 b3:01 934811 /usr/lib/locale/locale-archive 7f1e4a6b9000-7f1e4a6be000 rw-p 00000000 00:00 0 7f1e4a6dd000-7f1e4a6e0000 rw-p 00000000 00:00 0 7f1e4a6e0000-7f1e4a6e1000 r--p 00025000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a6e1000-7f1e4a6e2000 rw-p 00026000 b3:01 923087 /lib/x86_64-linux-gnu/ld-2.23.so 7f1e4a6e2000-7f1e4a6e3000 rw-p 00000000 00:00 0 7ffc3afc6000-7ffc3afe7000 rw-p 00000000 00:00 0 [stack] 7ffc3aff2000-7ffc3aff4000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Wrong exit code (expected 251 , actual 134 ) Stdout: Stderr: T5644: Heap exhausted; T5644: Current maximum heap size is 20971520 bytes (20 MB). T5644: Use `+RTS -M<size>' to increase it. Aborted (core dumped) *** unexpected failure for T5644(threaded1) }}} Similar result for `WAY=threaded2`. No problems with ghc-8.0.1. I'm using ghc-8.1.20160610 (c88f31a08943764217b69adb1085ba423c9bcf91). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12424: RTS stats show wrong productivity.
by GHC 25 Aug '16

25 Aug '16

#12424: RTS stats show wrong productivity. --------------------------------------+--------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I have this report after runnig my program: {{{ INIT time 0.000s ( 0.001s elapsed) MUT time 29.344s ( 56.484s elapsed) GC time 4.306s ( 1.589s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 33.649s ( 58.075s elapsed) Alloc rate 1,530,969,741 bytes per MUT second Productivity 87.2% of total user, 50.5% of total elapsed }}} Elapsed productivity is wrong. It should be `MUT elapsed / Total elapsed = 56.484 / 58.075 = 0.972` but it looks like `MUT user / Total elapsed = 29.344 / 58.075 = 0.505` Looks like the code at https://github.com/ghc/ghc/blob/a88bb1b1518389817583290acaebfd6454aa3cec/rt… uses wrong numerator for elapsed value. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12365: Update documentation for partial type signatures
by GHC 25 Aug '16

25 Aug '16

#12365: Update documentation for partial type signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- In the [https://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#partial-type-signatures documentation] for partial type signatures, I found several bits that are out of date: - There are several sample error messages given. These have been substantively reworded ({{{Found hole `_` with type: ...}}} to {{{Found type wildcard `_` standing for ...}}}) where I find the new wording much clearer. - In the "Where can they occur?" section, there's no mention of `TypeApplications`, which is a new context where they can appear. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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