December 2016 - ghc-tickets

[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

Re: [GHC] #314: #line pragmas not respected inside nested comments
by GHC 07 Dec '16

07 Dec '16

#314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't get fixed for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/314#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 07 Dec '16

07 Dec '16

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Looks like it! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7782: flag to run the demand analysis a second time
by GHC 07 Dec '16

07 Dec '16

#7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nomeata (added) Comment: nomeata, is this perhaps addressed by f4fd98c717a7f68d76a3054021b3be65d1ebad82? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7782#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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