- ghc-tickets - Haskell.org

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

08 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 08 Dec '16

08 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

Re: [GHC] #12914: Port SplitSections to Windows
by GHC 07 Dec '16

07 Dec '16

#12914: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8405 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12913 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12914#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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

[GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value
by GHC 07 Dec '16

07 Dec '16

#12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- At the moment `placeHolderPunRhs` is defined as {{{#!hs placeHolderPunRhs :: LHsExpr RdrName -- The RHS of a punned record field will be filled in by the renamer -- It's better not to make it an error, in case we want to print it when debugging placeHolderPunRhs = noLoc (HsVar pun_RDR) pun_RDR = mkUnqual varName (fsLit "pun-right-hand-side") }}} Rather use a type of `PostRn id (LHsExpr id)` where this is used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7