June 2016 - ghc-tickets

[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] #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] #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] #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function
by GHC 25 Aug '16

25 Aug '16

#12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Summary: Unlike GHC 7.10.2, when GHC 8.0.1 tries to compile a certain complex INLINE function with -O2 -ddump-hi, it runs out of memory. Dropping either -O2 or -ddump-hi enables successful compilation. Oddly enough, triggering the issue requires using the function argument indirectly through a variable bound by a "where" clause, even though it is obvious to a human reader that the indirection is trivial. (Even after simplifying the original code to work around the out of memory issue, that indirection greatly increases the size of the ".dump-hi" file. It might be that the "out of memory" would not happen if one had sufficient RAM.) Using INLINABLE instead of INLINE seems to result in a much smaller RHS being recorded for the function in question, and does not trigger the problem. (Perhaps INLINABLE records a more optimized RHS than does INLINE, though that is not obvious to me from the GHC User's Guide.) The attached files contain a reduced version of the original code that still triggers the problem. (Of course, the reduced version is rather artificial and pointless, other than to demonstrate the problem.) Probably someone with sufficient understanding could shrink the example further. Please note that I have worked around the issue, and so I am not blocked by this problem, at least not currently. Attachments: - crash.bash - Crash.hs Observed behavior: On 64-bit x86 Ubuntu 16.04 LTS, with the attached files in the current directory, GHC 7.10.2 succeeds: {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 7.10.2 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) }}} whereas GHC 8.0.1 runs out of memory (or wedges my system if I comment out both "ulimit" commands in the script): {{{ $ ./crash.bash The Glorious Glasgow Haskell Compilation System, version 8.0.1 [1 of 1] Compiling Crash ( Crash.hs, Crash.o ) ghc: out of memory }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12195: RTS GetTime.c is broken on Darwins that include clock_gettime
by GHC 25 Aug '16

25 Aug '16

#12195: RTS GetTime.c is broken on Darwins that include clock_gettime -------------------------------------+------------------------------------- Reporter: mistydemeo | 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: -------------------------------------+------------------------------------- GHC fails to build on versions of Darwin which include `clock_gettime`. On Darwin versions which include `clock_gettime`, the `#ifdef`s are structured to prefer using `clock_gettime` over the mach-specific time functions and structs; however, a couple of places in GetTime.c use the mach functions unconditionally even though the `mach/mach_time.h` header won't be included if `clock_gettime` is available. The attached patch fixes this by checking `HAVE_CLOCK_GETTIME` first before checking if the OS is Darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12195> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by GHC 25 Aug '16

25 Aug '16

#12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot} -------------------------------------+------------------------------------- Reporter: dudebout | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.0.1 Keywords: pkgroot | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash. Default behavior: $ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Correct behavior (no trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Incorrect behavior (with trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}. This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5