August 2018 - ghc-tickets

[GHC] #15390: Figure out why CircleCI isn't generating haddocks
by GHC 23 Aug '18

23 Aug '18

#15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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): You must have missed my edit where I describe such a "remembered set". When there are only two generations, there's only one such, and it can even be a static array (whose size is limited to a fixed fraction of the nursery size). When there are more generations, there are more options and they get harder to think about. Perhaps the way to start is with one hash table for underlying objects in the nursery and one for those in all other generations. I suspect that will give us a lot of the benefits with very few complications. My challenge is that I know very little about the details of garbage collection, so I don't really know how to write this stuff properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15059: ghcpkg05 fails
by GHC 23 Aug '18

23 Aug '18

#15059: ghcpkg05 fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 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: -------------------------------------+------------------------------------- Several people have noted that `ghcpkg05` seems to fail in some environments with (taken from CircleCI, https://circleci.com/gh/ghc/ghc/3654) {{{ --- ./cabal/ghcpkg05.run/ghcpkg05.stderr.normalised 2018-04-19 14:14:29.043902308 +0000 +++ ./cabal/ghcpkg05.run/ghcpkg05.run.stderr.normalised 2018-04-19 14:14:29.043902308 +0000 @@ -10,6 +10,13 @@ cannot find any of ["C/D.hi","C/D.p_hi","C/D.dyn_hi"] cannot find any of ["C/E.hi","C/E.p_hi","C/E.dyn_hi"] cannot find any of ["libtestpkg-2.0-XXX.a","libtestpkg-2.0-XXX.p_a","libtestpkg-2.0-XXX- ghc<VERSION>.so","libtestpkg-2.0-XXX-ghc<VERSION>.dylib","testpkg-2.0-XXX- ghc<VERSION>.dll"] on library path +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/utils doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/../rts/dist/build doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/compiler/stage2/build/stage2 doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/haskeline/dist- install/build/includes doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/text/dist- install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/containers/dist- install/build/include doesn't exist or isn't a directory +Warning: include-dirs: /home/ghc/project/libraries/bytestring/dist- install/build/include doesn't exist or isn't a directory The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. *** unexpected failure for ghcpkg05(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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 simonmar): I can't off-hand think of a reason why no-stable-name-table wouldn't work. Seems reasonable to me. A per-generation hash table is tricky because each entry is associated with two heap objects: the key and the `StableName` object, which may be in different generations. The hash table is keyed by the key (we really need a different name for that), so obviously it's the `StableName` object that might reside in a different generation. You would probably need something like a remembered set, to remember which hash table entries point to a StableName in a younger generation and therefore might need updating during a young-gen collection. I'm sure that's not the only design though. It's worth considering that you could do no-stable-name-table without per- generation hash tables, as an intermediate step. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64
by GHC 23 Aug '18

23 Aug '18

#4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): There are no bindists for FreeBSD anymore. What should be done to bring them back? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4022#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #14973, #15087, #15165, #15213, #15535
by GHC 23 Aug '18

23 Aug '18

Batch modification to #14973, #15087, #15165, #15213, #15535 by RyanGlScott: milestone to 8.6.1 Comment: These were marked as merge, but not milestoned properly. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=14973%2C15087%2C15165%2C15213%2C15…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10100: Bogus "redundant constraint" warning with functional dependencies
by GHC 23 Aug '18

23 Aug '18

#10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module T10100 where data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Gives a bogus warning about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14336: ghci leaks memory
by GHC 23 Aug '18

23 Aug '18

#14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following script spawns ghci, and that spawned ghci then goes on to leak memory: {{{#!hs import Control.Concurrent import Control.Monad import System.IO import System.Process main = do (Just hin, Nothing, Nothing, pid) <- createProcess (proc "ghci" ["+RTS","-S"]){std_in=CreatePipe} forever $ do threadDelay 100000 -- 0.1s hPutStrLn hin "\"this is a test of outputting stuff\"" hFlush hin }}} This script just writes a string to GHCi, which then echos it back. The {{{+RTS -S}}} is useful to watch the live memory tick up in realtime, but it leaks without it, and the leak can be seen in process explorer (87Mb to 700Mb over about 30 minutes). While repeatedly writing commands may not be a standard usage of ghci, it is when driven by tools such as ghcid (https://hackage.haskell.org/package/ghcid) and other IDE-like uses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #14917: Allow levity polymorhism in binding position
by GHC 22 Aug '18

22 Aug '18

#14917: Allow levity polymorhism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The main problem with levity polymorphism in a binding position is that it's impossible to do codegen since the calling convention depending on the instantiation of the runtime representation variable. From the paper, we have the following rejected example code: {{{ bTwice :: ∀ (r :: RuntimeRep) (a :: TYPE r). Bool → a → (a → a) → a }}} However, if you are able to inline the function, this problem disappears. You would need a guarantee stronger than what the `INLINE` pragma provides though since the `INLINE` pragma still allows the function to be fed as an argument to a higher-order function. I'll refer to a hypothetical new pragma as `INLINE MANDATE`. This pragma causes a compile-time error to be admitted if the function is ever used in a way that would cause it to not be inlined. Now `bTwice` would be writeable: {{{ {-# INLINE MANDATE #-} bTwice :: ∀ (r :: RuntimeRep) (a :: TYPE r). Bool → a → (a → a) → a }}} The function definition would be provide in the `.hi` file just as it would be for a function marked as `INLINE`, but unlike the `INLINE` counterpart, there would be no generated code for this function, since generating the code would be impossible. I have several uses for this in mind. I often want a levity-polymorphic variant `ST`. With `INLINE MANDATE`, I still wouldn't get `do` notation, but I could write: {{{ -- This newtype is already allowed today newtype STL s (a :: TYPE r) = STL (State# s -> (# s, a #) #) intA, intB, intC :: STL s Int# wordA, wordB :: Int# -> STL s Word# {-# INLINE MANDATE #-} (>>=.) :: STL s a -> (a -> STL s b) -> STL s b STL a >>=. g = STL (\s0 -> case a s0 of (# s1, v #) -> case g v of STL f -> f s1 myFunc :: STL s Word# myFunc = intA >>=. \a -> intB >>=. \b -> intC >>=. \c -> wordA a >>=. \wa -> wordB b >>=. \wb -> ... -- do something with the data }}} I would appreciate any feedback on this. If there's something that makes this fundamentally impossible, that would be good to know. Or if other people feel like this would be useful, that would be good to know as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14917> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #15543: Binary crashes under dtrace
by GHC 22 Aug '18

22 Aug '18

#15543: Binary crashes under dtrace -------------------------------------+------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.4.3 Keywords: dtrace, crash | Operating System: MacOS X Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I'm trying to attach to the simple binary with DTrace command ({{{sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` }}}) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch. Crashes: {{{ lastg-mbp:t lastg$ ./FibbSlow.master 55 FibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B (GHC version 8.7.20180817 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548 (GHC version 8.4.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548 (GHC version 8.4.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 Segmentation fault: 11 }}} Source code for the binary: https://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2