September 2016 - ghc-tickets

[GHC] #8668: SPECIALIZE silently fails to apply
by GHC 07 Dec '16

07 Dec '16

#8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342) There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics
by GHC 07 Dec '16

07 Dec '16

#11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: Segmentation | Operating System: Unknown/Multiple Fault, Generics, Runtime error | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: attached | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproduced issue on both Windows-7/GHC-7.10.3 and Linux-4.1.15/GHC-7.8.4 Seems to probably be a problem with GHC.Generics and the runtime. Windows/GHC-7.10.3 states: internal error: evacuate: strange closure type 15 (GHC version 7.10.3 for x86_64_unkown_mingw32) Please report this as a GHC bug: httpL//www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Linux/GHC-7.8.4 states: Segmentation fault Behavior varies based on CSV input file size, a CSV file with header with 1 to 4 rows works. A CSV with a header and more than 10 rows segmentation faults imediatly. Inbetween 4 to 10 sometimes runs forever, works, or segmentation faults. The test case uses Cassava and GHC.Generics and some derived instances to read a CSV file with a record data type with many fields. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11703> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12591: Profiled build broken
by GHC 07 Dec '16

07 Dec '16

#12591: Profiled build broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- As of 045f83ed39dba537b3da46465bd7a155c754f120 the `BuildFlavour=prof` build appears to be broken. The stage2 build appears to reproducibly fail with, {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -this-unit-id ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id binary-0.8.3.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.2.0 -package-id template- haskell-2.11.0.0 -package-id time-1.6.0.1 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O -fprof-auto-top -fprof-cafs -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/codeGen/StgCmmMonad.hs -o compiler/stage2/build/StgCmmMonad.p_o -dyno compiler/stage2/build/StgCmmMonad.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160912 for x86_64-unknown-linux): kindPrimRep.go k0_10 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck
by GHC 07 Dec '16

07 Dec '16

#10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals periodic alarm signals emitted by the GHC RTS] can [https://github.com/haskell/directory/issues/35 hang the program under certain circumstances]. In particular, any retry-loop of the form {{{#!c while (interruptible_syscall() == FAILED && errno == EINTR); }}} can cause a hang if the syscall takes a long time and cannot be resumed, as it will forced to restart from the beginning each time it gets interrupted. If the syscall takes longer than the interval between successive alarm signals, it will be stuck in this loop forever. This was found to occur with `statfs64` (indirectly called by `realpath`) and `open` on SSHFS on Mac OS X. [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009770.html Using a safe foreign import seems to mitigate the issue], but [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009793.html according to Simon Marlow this is probably an accident]. So far there seems to be no way to guarantee the suspension of signals except through low-level tools like `pthread_setmask`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #9314: Huge space leak of GHC API 7.8.x
by GHC 07 Dec '16

07 Dec '16

#9314: Huge space leak of GHC API 7.8.x ------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC API 7.8.x uses much more memory than GHC API 7.6.x. Attached two files demonstrate this: - A.hs -- Simple program using GHC API (copied from Wiki) - B.hs -- A target file, just hello world You can compile A.hs as follows: {{{ % ghc A.hs -package ghc -package ghc-paths }}} A.hs stays in 10 seconds. So, we can investigate its memory usage with the "top" command.The following is the result: {{{ Mac (64bit) Linux (64bit) GHC 7.6.3: 20MB 4MB GHC 7.8.3: 106MB 13MB }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell
by GHC 07 Dec '16

07 Dec '16

#12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bit me just now, so I figured I should report a feature request bug. {{{ ezyang@sabre:~/Dev/whisk$ ghc-8.0 --interactive -XTemplateHaskell GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Prelude> Language.Haskell.TH.runQ [| \(x :: ()) -> x |] <interactive>:1:29: error: Type signatures in patterns not (yet) handled by Template Haskell x :: () }}} In the code, there is a bit of mumbling about scoped type variables. I believe it is referring to code like this: {{{ Prelude> :t (\(x :: a) -> (x :: a)) (\(x :: a) -> (x :: a)) :: a -> a }}} Described in the manual here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #pattern-type-signatures This means that TH has to somehow bring the type into scope. I don't actually know how to do it. It seems a bit awful for this to be the reason why these quotes are not accepted; maybe without scoped type variables we should be able to do something cheap and cheerful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8460: Annotation reification with types in TH
by GHC 07 Dec '16

07 Dec '16

#8460: Annotation reification with types in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8397 | Test Case: | Blocking: -------------------------------------------+------------------------------- The attached patch adds two simple helper functions to support typed reification of annotations. This was not in the original #8397 patch only because the typed branch was not merged at that time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9813: Error when reifying type constructor
by GHC 07 Dec '16

07 Dec '16

#9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Huh = ThisDefinitely | UsedToWork constructorNames :: String constructorNames = $(do ty <- reify ''Huh let showCon (NormalC n _) = nameBase n strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons return . LitE . StringL $ concat strs) main = putStrLn constructorNames }}} Printing the following at compile time: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main ... }}} and then successfully executing: {{{ $ ./Main ThisDefinitelyUsedToWork }}} However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Main.hs:8:22: ‘Huh’ is not in the type environment at a reify In the splice: $(do { ty <- reify ''Huh; let showCon (NormalC n _) = ... ....; return . LitE . StringL $ concat strs }) }}} Is this expected? I couldn't see anything in the GHC release notes to suggest this should no longer work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #12455: Compact Regions
by GHC 07 Dec '16

07 Dec '16

#12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- I'm going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Improve comments -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12404: Document version availability for each language extension
by GHC 07 Dec '16

07 Dec '16

#12404: Document version availability for each language extension -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A certain amount of "historical" information about language extensions is of sufficient practical utility to deserve a place in the GHC documentation. I believe that the documentation for each language extension should include 1. The GHC version in which it first appeared. 2. Any major changes that have been made to the extension since the previous major-major version. For example, the GHC 8.x.x documentation for any given language extension should include any major changes to it since 7.0.1. At present, the only way I see to get this information is to dig through previous versions of the documentation and change logs, which is rather inefficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3