August 2018 - ghc-tickets

[GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message
by GHC 23 Aug '18

23 Aug '18

#15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} -- {-# LANGUAGE UndecidableInstances #-} module Bug where type family Undefined :: k where {} type family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where LetInterleave xs t ts is y z = Undefined y z }}} You'll get this far: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:3: error: • Variables ‘a, a’ occur more often in the type family application }}} Before GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.) Interestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 23 Aug '18

23 Aug '18

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Another thing: we don't really want to have to allocate memory dynamically for the nursery hash table. Ideally, it would be backed by a fixed array to avoid memory management overhead. The non-nursery hash table can be a bit more expensive to maintain, since it only gets replaced during major collections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9688: Improve the interaction between CSE and the join point transformation
by GHC 23 Aug '18

23 Aug '18

#9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: CSE | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears that the join point transformation sometimes interferes with CSE when CSE would be much better. Two examples: === digitToIntMaybe === Suppose we define {{{#!hs isHexDigit :: Char -> Bool isHexDigit c = (fromIntegral (ord c - ord '0')::Word) <= 9 || (fromIntegral (ord c - ord 'a')::Word) <= 5 || (fromIntegral (ord c - ord 'A')::Word) <= 5 digitToInt c | (fromIntegral dec::Word) <= 9 = dec | (fromIntegral hexl::Word) <= 5 = hexl + 10 | (fromIntegral hexu::Word) <= 5 = hexu + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) -- sigh where dec = ord c - ord '0' hexl = ord c - ord 'a' hexu = ord c - ord 'A' -- We could also expand this out in cases manually, but it makes no -- difference as far as I can tell. }}} Suppose we then write a naive `digitToIntMaybe` function: {{{#!hs digitToIntMaybe c | isHexDigit c = Just (digitToInt c) | otherwise = Nothing }}} What I would want this to do is "zip" the nested cases and give Core like this: {{{ $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Ag -> let { x#_a2yy x#_a2yy = -# (ord# ww_s2Ag) 48 } in case tagToEnum# (leWord# (int2Word# x#_a2yy) (__word 9)) of _ { False -> let { x#1_X2z7 x#1_X2z7 = -# (ord# ww_s2Ag) 97 } in case tagToEnum# (leWord# (int2Word# x#1_X2z7) (__word 5)) of _ { False -> let { x#2_X2zh x#2_X2zh = -# (ord# ww_s2Ag) 65 } in case tagToEnum# (leWord# (int2Word# x#2_X2zh) (__word 5)) of _ { False -> Nothing; True -> Just (I# (+# x#2_X2zh 10)) }; True -> Just (I# (+# x#1_X2z7 10)) }; True -> Just (I# x#_a2yy) } digitToIntMaybe digitToIntMaybe = \ w_s2Ad -> case w_s2Ad of _ { C# ww1_s2Ag -> $wdigitToIntMaybe ww1_s2Ag } }}} But instead, the join point transformation triggers, and we get this: {{{ digitToIntMaybe1 digitToIntMaybe1 = \ ww_s2Cp -> error (unpackAppendCString# "Char.digitToInt: not a digit "# ($w$cshowsPrec15 ww_s2Cp ([]))) $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Cp -> let { $j_s2Bc $j_s2Bc = \ _ -> Just (let { a_s2B5 a_s2B5 = int2Word# (-# (ord# ww_s2Cp) 48) } in case tagToEnum# (leWord# a_s2B5 (__word 9)) of _ { False -> let { a1_s2B7 a1_s2B7 = int2Word# (-# (ord# ww_s2Cp) 97) } in case tagToEnum# (leWord# a1_s2B7 (__word 5)) of _ { False -> let { a2_s2B9 a2_s2B9 = int2Word# (-# (ord# ww_s2Cp) 65) } in case tagToEnum# (leWord# a2_s2B9 (__word 5)) of _ { False -> digitToIntMaybe1 ww_s2Cp; True -> I# (+# (word2Int# a2_s2B9) 10) }; True -> I# (+# (word2Int# a1_s2B7) 10) }; True -> I# (word2Int# a_s2B5) }) } in case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 48)) (__word 9)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 97)) (__word 5)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 65)) (__word 5)) of _ { False -> Nothing; True -> $j_s2Bc void# }; True -> $j_s2Bc void# }; True -> $j_s2Bc void# } digitToIntMaybe digitToIntMaybe = \ w_s2Cm -> case w_s2Cm of _ { C# ww1_s2Cp -> $wdigitToIntMaybe ww1_s2Cp } }}} We perform the same three tests twice each, and test for an error condition that obviously can't happen. === `quotRem` and `divMod` === If we define {{{#!hs x `quot` y = fst (x `quotRem` y) x `rem` y = snd (x `quotRem` y) }}} and then write something like {{{#!hs f x y | x `rem` y == 0 = x `quot` y | otherwise = 17 }}} then CSE works some magic and we only calculate `quotRem x y` once. Unfortunately, if we do this: {{{#!hs whatever x y = if x `myRem` y == 0 then (x `myQuot` y) + 14 else x `myQuot` y }}} then the join point transformation fires, collecting the `myQuot x y` expressions in the case branches and preventing CSE from recognizing the much better opportunity to eliminate those calculations altogether. The situation with `divMod` is much worse. The join point transformation applied to the cases defining `divMod` prevents CSE from working magic on it in even simple situations, unless one of the arguments is known, making this definition unusable (the resulting Core is too horrifyingly long to paste here). It would probably be possible to improve the `divMod` situation to something close to the `quotRem` one by making `divMod` `NOINLINE` and adding special `divModLit` rules, but I'd much rather see a general solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15442: GhcStage3HcOpts passed to ghc-stage1
by GHC 23 Aug '18

23 Aug '18

#15442: GhcStage3HcOpts passed to ghc-stage1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 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: -------------------------------------+------------------------------------- When building a stage3 compiler the build system passes `GhcStage3HcOpts` to `inplace/bin/ghc-stage1` while building dependency lists: {{{ $ make stage=3 GhcStage3HcOpts='+RTS -xn -RTS "inplace/bin/ghc-stage1" -M -fPIC -dynamic -H32m -O -Wall -hide-all- packages -i -ighc/. -ighc/stage3/build -Ighc/stage3/build -ighc/stage3/build/ghc/autogen -Ighc/stage3/build/ghc/autogen -optP- DGHCI -optP-include -optPghc/stage3/build/ghc/autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghci-8.7 -package-id haskeline-0.7.4.2 -package-id process-1.6.3.0 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.8.0.0 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -XHaskell2010 -O2 +RTS -xn -RTS -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage3/build -hidir ghc/stage3/build -stubdir ghc/stage3/build -dep-makefile ghc/stage3/build/.depend.haskell.tmp -dep-suffix "dyn_" -include-pkg-deps ghc/./Main.hs ghc/./GHCi/Leak.hs ghc/./GHCi/UI.hs ghc/./GHCi/UI/Info.hs ghc/./GHCi/UI/Monad.hs ghc/./GHCi/UI/Tags.hs ghc-stage1: unknown RTS option: -xn ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15517: haddock triggers panic in trimJoinCont
by GHC 23 Aug '18

23 Aug '18

#15517: haddock triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running haddock on the [https://github.com/VictorCMiraldo/generics-mrsop `generics-mrsop`] package results in {{{ haddock: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): completeCall fail_av9P Select nodup wild_00 Stop[BoringCtxt] Rep Singl (El FamRoseInt) (Lkup ix CodesRoseInt) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1533:9 in ghc:Simplify }}} The same problem affects 8.6.1 and HEAD, but not 8.2.2. The panic seems to stem from [https://github.com/ghc/ghc/blob/64c71ce956af3af593a46ef0d615c7f6fe6ecece/co… this catch-all in `trimeJoinCont`]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC
by GHC 23 Aug '18

23 Aug '18

#15213: 32 bit Haddock runs out of memory compiling 32 bit GHC --------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Final parts of stage2 fails with {{{ Warning: DriverBkp: could not find link destinations for: BkpEnv BkpM backpackProgressMsg haddock.exe: Out of memory make[1]: *** [compiler/ghc.mk:448: compiler/stage2/doc/html/ghc/ghc.haddock] Error 251 make: *** [Makefile:127: all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15165: GHC 8.2.2: internal error with +RTS -hb
by GHC 23 Aug '18

23 Aug '18

#15165: GHC 8.2.2: internal error with +RTS -hb --------------------------------------+---------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- Hi, I'm trying to generate a heap profile via "+RTS -hb" on macOS 10.13.4. Unfortunately I get the following error: `internal error: Invalid object in processHeapClosureForDead(): 7`\\ `(GHC version 8.2.2 for x86_64_apple_darwin)`\\ `Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug`\\ `Abort trap: 6` Best regards Doro -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15087: Internal Error with Bibliography Profiling
by GHC 23 Aug '18

23 Aug '18

#15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When running my large program with `+RTS -hb`, I get the following error: {{{ internal error: Invalid object in processHeapClosureForDead(): 7 (GHC version 8.4.2 for x86_64_unknown_linux) }}} Unfortunately, I'm unable to find a minimal example. (Side note: I doubt this is relevant, but this is a multi-threaded program. I first tried to profile with `+RTS -N4 -hb`, but got `-hb cannot be used with multiple capabilities`. I assumed this means it doesn't like `-N4` with `-hb`, so I removed `-N4` and got the above error.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used
by GHC 23 Aug '18

23 Aug '18

#14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.5 Keywords: debugger | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Noticed in #8316) Test.hs: {{{#!haskell foo :: [Int] foo = [ 1 .. 10 ] }}} Reproducer: {{{ $ ghc-stage2 --interactive -ignore-dot-ghci Test.hs GHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Test.hs, interpreted ) Ok, one module loaded. *Main> :break foo Breakpoint 0 activated at Test.hs:2:7-14 *Main> foo Stopped in Main.foo, Test.hs:2:7-14 _result :: [Int] = _ [Test.hs:2:7-14] [Test.hs:2:7-14] *Main> }}} The `[Test.hs:2:7-14]` part is repeated. Setting the prompt fixes it: {{{ $ ghc-stage2 --interactive Test.hs -ignore-dot-ghci GHCi, version 8.5.20180325: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Test.hs, interpreted ) Ok, one module loaded. *Main> :set prompt "> " > :break foo Breakpoint 0 activated at Test.hs:2:7-14 > foo Stopped in Main.foo, Test.hs:2:7-14 _result :: [Int] = _ [Test.hs:2:7-14] > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14973> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64
by GHC 23 Aug '18

23 Aug '18

#15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling GHC with clang and -march=native flag, the compiler emits vmovaps instruction with unaligned operand for this code: {{{ * thread #1, name = 'ghc-pkg', stop reason = signal SIGBUS: hardware error frame #0: 0x0000000804e476c6 libHSrts-ghc8.0.2.so`initGcThreads [inlined] new_gc_thread(n=0) at GC.c:818 815 ws->todo_q = newWSDeque(128); 816 ws->todo_overflow = NULL; 817 ws->n_todo_overflow = 0; -> 818 ws->todo_large_objects = NULL; 819 820 ws->part_list = NULL; 821 ws->n_part_blocks = 0; }}} Research done by another FreeBSD developer suggested that this is due {{{ StgWord8 the_gc_thread[sizeof(gc_thread) + 64 * sizeof(gen_workspace)]; }}} not being aligned to 64 bytes, because struct gc_thread have no alignment specifier. Detailed information can be found in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226059 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13