- ghc-tickets - Haskell.org

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 23 Aug '18

23 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 23 Aug '18

23 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

[GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag
by GHC 23 Aug '18

23 Aug '18

#15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15534: Allow associated types in Minimal pragmas
by GHC 23 Aug '18

23 Aug '18

#15534: Allow associated types in Minimal pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- Missing associated type definitions can cause compile-time problems similar to the run-time problems that occur when necessary methods are missing. {{{#!hs {-# language TypeFamilies, UndecidableInstances #-} class Foo a where type X a type X a = Y a type Y a type Y a = X a instance Foo Int bob :: X Int bob = undefined }}} Compiling this gives {{{ Minim.hs:14:7: error: • Reduction stack overflow; size = 201 When simplifying the following type: Y Int Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘bob’: bob = undefined | 14 | bob = undefined }}} That's not exactly the best error message in the world. I would like to be able to write {{{#!hs {-# MINIMAL X | Y #-} }}} which would mean that instances should give type instances for `X` or `Y`. I don't see any reason to prohibit mixing associated types and methods in a single `MINIMAL` pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15556: Inconsistent kind output for (->)
by GHC 23 Aug '18

23 Aug '18

#15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The kind for (->) seems to be (uniquely?) verbose in ghc >= 8.2.2: {{{(->) :: TYPE q -> TYPE r -> *}}} Unlike all other things I was able to check. Is this intended? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4