November 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] #12866: GHC internal error while building darcsden
by GHC 07 Dec '16

07 Dec '16

#12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | 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: -------------------------------------+------------------------------------- I get an internal error while building darcsden with GHC 8.0.1: $ darcs get hub.darcs.net:simon/darcsden-ghc8 $ cd darcsden-ghc8 $ stack --stack-yaml=stack-ghc8.yaml build ... [12 of 56] Compiling DarcsDen.Backend.Transient ( src/DarcsDen/Backend/Transient.hs, .stack- work/dist/i386-linux/Cabal-1.24.0.0/build/DarcsDen/Backend/Transient.o ) /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:10:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ajE2 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:44:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ -- While building package darcsden-1.1.99 using: /home/simon/.stack/setup-exe-cache/i386-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/i386-linux/Cabal-1.24.0.0 build lib:darcsden exe:darcsden exe :darcsden-post-hook exe:da... Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12652: Type checker no longer accepting code using function composition and rank-n types
by GHC 07 Dec '16

07 Dec '16

#12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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 program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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