- ghc-tickets - Haskell.org

[GHC] #14096: Residency profiling with eventlog enabled breaks
by GHC 20 Sep '17

20 Sep '17

#14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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 RTS panics when a program compiled with `-eventlog` is run with `+RTS -l -h`, {{{ trec-car-graph-expansion: internal error: getHeapProfBreakdown: unknown heap profiling mode Stack trace: 0x2122e2f set_initial_registers (rts/Libdw.c:288.0) 0x7f98bbdfb8b8 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.168.so) 0x7f98bbdfb347 (null) (/usr/lib/x86_64-linux- gnu/libdw-0.168.so) 0x7f98bbdfb673 dwfl_getthreads (/usr/lib/x86_64-linux- gnu/libdw-0.168.so) 0x7f98bbdfbc30 dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.168.so) 0x212342d libdwGetBacktrace (rts/Libdw.c:259.0) 0x2127aab rtsFatalInternalErrorFn (rts/RtsMessages.c:169.0) 0x2127c6d barf (rts/RtsMessages.c:47.0) 0x2136824 postHeapProfBegin (rts/eventlog/EventLog.c:1147.0) 0x21443bb initHeapProfiling.part.5 (rts/ProfHeap.c:464.0) 0x211cc16 hs_init_ghc (rts/RtsStartup.c:268.0) 0x2128bb3 hs_main (rts/RtsMain.c:63.0) 0x4cfc8d (null) (/home/ben/trec-car/mediawiki- annotate/dist-newstyle/build/x86_64-linux/ghc-8.2.1/trec-car-graph- expansion-0.1.0.0/c/trec-car-graph-expansion/bu ild/trec-car-graph-expansion/trec-car-graph-expansion) 0x7f98bba4a2b1 __libc_start_main (../csu/libc- start.c:325.0) 0x40ba1a _start (/home/ben/trec-car/mediawiki- annotate/dist-newstyle/build/x86_64-linux/ghc-8.2.1/trec-car-graph- expansion-0.1.0.0/c/trec-car-graph-expansion/bu ild/trec-car-graph-expansion/trec-car-graph-expansion) (GHC version 8.2.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14163: Stack Overflow with ApplicativeDo
by GHC 20 Sep '17

20 Sep '17

#14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to compile one of our server applications with 8.2.1 (which compiles fine with 8.0.2). The compilation runs smooth, but when it reaches a specific file, the RAM usage goes up to > 20GB pretty fast on my 16GB machine and the GHC process gets terminated with a stack overflow error. I tried to find a minimal example that causes this behavior: {{{ #!/usr/bin/env stack -- stack --resolver nightly-2017-08-25 script {-# LANGUAGE ApplicativeDo #-} x = do (a, _) <- undefined (b, _) <- undefined (c, _) <- undefined undefined main = undefined }}} It only happens with at least 3 of these pattern matches. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums
by GHC 20 Sep '17

20 Sep '17

#14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: UnboxedSum, | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following implementation of `Maybe` using UnboxedSums results in `Non- exhaustive patterns in case`: (`Failure.hs` file) {{{#!haskell {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE PatternSynonyms #-} type Maybe' t = (# t | () #) pattern Just' :: a -> Maybe' a pattern Just' x = (# x | #) pattern Nothing' :: Maybe' a pattern Nothing' = (# | () #) foo x = case x of Nothing' -> putStrLn "nothing" Just' _ -> putStrLn "just" main = do putStrLn "Nothing'" foo Nothing' putStrLn "Just'" foo (Just' "hello") }}} When executed, it prints: {{{ Nothing' nothing Just' Failure: Failure.hs:10:20-29: Non-exhaustive patterns in case }}} Compiled with `ghc Failure.hs`. Please note that by removing the `pattern`s, and writting `foo` as following works as expected: {{{#!haskell foo x = case x of (# | () #) -> putStrLn "nothing" (# _ | #) -> putStrLn "just" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14189: Renamer does not preserve location for IEThingWith list items
by GHC 20 Sep '17

20 Sep '17

#14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the `RenamedSource` for {{{#!hs module Renaming.RenameInExportedType ( MyType (NT) ) where data MyType = MT Int | NT }}} The `(NT)` is given the location of `MyType` earlier on the line in the export list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic
by GHC 19 Sep '17

19 Sep '17

#14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci -XTypeApplications GHCi, version 8.3.20170605: http://www.haskell.org/ghc/ :? for help Prelude> import qualified Control.Category as Cat Prelude Cat> :t (Cat.id @(->) >>=) ghc: panic! (the 'impossible' happened) (GHC version 8.3.20170605 for x86_64-unknown-linux): repSplitAppTy_maybe a0_a1qW[tau:2] a0_a1qW[tau:2] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:699:5 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Cat> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13525: hWaitForInput with timeout causes program to abort
by GHC 19 Sep '17

19 Sep '17

#13525: hWaitForInput with timeout causes program to abort --------------------------------------+---------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- This program, {{{#!hs import System.IO import System.Timeout main = hWaitForInput stdin (5 * 1000) }}} causes the program to abort (tested on Linux), {{{ $ ghc hi.hs [1 of 1] Compiling Main ( hi.hs, hi.o ) Linking hi ... $ ./hi fdReady: msecs != 0, this shouldn't happenAborted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9157: cmm common block not eliminated
by GHC 19 Sep '17

19 Sep '17

#9157: cmm common block not eliminated ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in. In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code. BTW, this is how they match in France. {{{ #!ocaml type alt = A of int | B of int | C of int | D of int let g x = match x with A v | B v | C v | D v -> v }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14235: Suspiciously missing closure types in isRetainer
by GHC 19 Sep '17

19 Sep '17

#14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.2.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: -------------------------------------+------------------------------------- `RetainerProfile:isRetainer` has a switch on closure types which appears to be lacking several defined types. * `BLOCKING_QUEUE`: someone actually came into `#ghc` complaining about a crash due to this one * `WHITEHOLE` * `SMALL_MUT_ARR_PTRS_CLEAN` * `SMALL_MUT_ARR_PTRS_DIRTY` * `SMALL_MUT_ARR_PTRS_FROZEN0` * `SMALL_MUT_ARR_PTRS_FROZEN` * `COMPACT_NFDATA` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14235> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint
by GHC 19 Sep '17

19 Sep '17

#14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint --------------------------------------+--------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: ApplicativeDo | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Pattern matching on a bind in 8.2.1 confuses ApplicativeDo, and causes the type to have a Monad constraint where a Functor constraint would suffice. In GHC 8.0: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b, Functor f) => f (b, t) -> f b }}} In GHC 8.2: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b1, Monad m) => m (b1, b2) -> m b1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7277: Recompilation check fails for TH unless functions are inlined
by GHC 19 Sep '17

19 Sep '17

#7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: orenbenkiki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7277#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0