April 2018 - ghc-tickets

Re: [GHC] #2721: Newtype deriving doesn't work with type families
by GHC 12 Apr '18

12 Apr '18

#2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: TypeFamilies, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies => TypeFamilies, deriving -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2721#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 12 Apr '18

12 Apr '18

#7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | 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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Currently, GHC uses a round-robin scheduler for Haskell threads, with > some heuristics for when threads should be bumped to the front of the > queue. This patch set replaces this scheduler with 'stride scheduling', > as described by Waldspurger and Weihl '95, which is an efficient, > deterministic method for scheduling processes with differing priorities. > Priorities are assigned by giving 'tickets' to threads; a thread with > twice as many tickets as another will run twice as often. I’d like to > replace the round-robin scheduler completely with this scheduler. > > Here are nofib benchmarks comparing the old scheduler to the new: > > {{{ > -------------------------------------------------------------------------------- > Program Size Allocs Runtime Elapsed TotalMem > -------------------------------------------------------------------------------- > Min -0.0% -52.2% -18.8% -18.6% -83.1% > Max +1.0% +4.2% +4.9% +5.1% +7.7% > Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% > }}} > > Here are some technical details: > > * Without any changes to ticket values, scheduling behavior should be > functionally identical to round-robin. (By default, new threads, > including the IO thread, get allocated the max nubmer of tickets > possible.) This is not quite identical, since our heap does not have FIFO > property (see below.) > > * The current patch-set uses a very simple (e.g. undergrad level) > resizable-array backed heap to implement the priority queue; we can play > some tricks to reduce the memory footprint of the priority queue (e.g. > using the container_of macro to eliminate the extra keys store); and a > more fancy data structure would make it easier for us to surgically > remove entries or reweight them, but I wanted to keep overhead low. If > anyone has a pet implementation of priority queues in C feel free to swap > it in. Right now, this only affects the uses of promoteInRunQueue() in > Messages.c; I still need to check if #3838 has regressed. > > * We get three new primops: `setTickets#`, `getTickets#` and > `modifyTickets#`. We don't support creating threads with specific numbers > of tickets (mostly because that would have added an annoyingly large set > of extra primops); instead, you're expected to spawn a thread which gets > max-ticket allocation, and then weight it down. > > * `_link` is no longer used for linking TSOs in the run queue. I have > tried my best to stamp out any code which operated on this assumption, > but I may have missed some. > > * Modifying a TSO's tickets takes out the scheduler lock; the hope is > that this operation is quick and rare enough that a global lock here is > not too bad. > > * We are unfortunately stuck with some magic constants w.r.t. ticket > values: 1 << 20 is the maximum number of tickets our implementation is > hard-coded to support. > > * Sleeping and blocked tasks do not get any 'bonus' for being blocked. > > * In an ideal world, when a thread hits a black hole, it should > temporarily give its tickets to the thread evaluating the black hole, so > it will unblock more quickly. Unfortunately, implementing this is pretty > complicated (the blackhole evaluating thread could die; or it could get > stuck on a blackhole itself and need to gift its tickets; it shouldn't be > able to give away the tickets it was gifted.) So this implementation > leaves that out. Similar semantics for MVars are probably possible, but > will require userland assistance too. > > I haven't prepared a patch to base yet with a user-level API, but here is > a proposed draft: > > {{{ > type Tickets = Int > > -- | Maximum number of tickets we support a thread having. (Currently 2 > >> 20) > -- Note that this doesn't bound the *global* maximum tickets. > maxTickets :: Tickets > > -- | Changes the number of tickets allocated to a thread. The ticket > count must > -- not be less than or equal to zero, or greater than maxTickets. > (Corresponds > -- to setTickets# primop) > setTickets :: ThreadId -> Tickets -> IO () > > -- | Returns the number of tickets currently allocated to a thread. > (Corresponds to > -- getTickets# primop) > getTickets :: ThreadId -> IO Tickets > > -- | Atomically performs a linear transformation on the number of tickets > a thread; > -- e.g. scaling the number of tickets by a rational number, adding > another fixed > -- set of tickets, and then returning the number of 'leftover' tickets > from the operation; e.g. > -- if the net amount of tickets is reduced, then the returned result is > positive; > -- if the net amount of tickets is increased, the returned result is > negative. > -- In the absence of concurrent threads, the following property holds > forall > -- t, m and x: > -- > -- do r <- getTickets t > -- d <- scaleTickets t m x > -- r' <- getTickets t > -- return (r == r' + d) > -- > -- If the scaling would reduce the number of tickets below zero or > increase the > -- number of tickets beyond maxTickets, this function will instead fail > with > -- an exception. This function will be subject to some rounding error; > powers of two > -- are, however, likely to be exact. (Corresponds to modifyTickets# > primop; note > -- that the sentinel value for failure is maxTickets + 1, since it is > impossible for > -- a thread's ticket value to change by that much.) > modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets > > -- | Forks a new thread, transferring some percentage of tickets from the > current > -- thread to it (so the net number of tickets stays constant.) Fails if > the rational > -- is greater than 1 or less than or equal to zero, or if there are not > enough tickets > -- in the current thread. > forkIOWith :: IO a -> Ratio Int -> IO ThreadId > > }}} New description: Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by [http://read.seas.harvard.edu/~kohler/class/aosref/waldspurger95stride.pdf Waldspurger and Weihl '95], which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round- robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15030: Cabal Installation error in Windows 10 machine for Haskell
by GHC 12 Apr '18

12 Apr '18

#15030: Cabal Installation error in Windows 10 machine for Haskell --------------------------------+---------------------------- Reporter: gavinnf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------- When installing Haskell in my Windows 10 machine and executing the following at GitBash MinGw64 prompt $ cabal install doctest hindent stylish-haskell tasty tasty-hunit tasty- quickcheck codeworld-api The error attached displayed after the installation . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15031: [1,1..0] /= [1,1..2]
by GHC 12 Apr '18

12 Apr '18

#15031: [1,1..0] /= [1,1..2] -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.2.2 libraries/base | 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'm currently refactoring `efdtIntFB` into something that fuses better (#8763). While testing my prototype, I noticed that in current base `[1,1..x]` for `x` < 1 has different behavior than I expected: `[1,1..0] == []`. In comparison, the `x` == 1 or > 1 case yields `repeat 1`. Is this expected and/or specified somewhere? If so, I find this rather surprising. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15031> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 12 Apr '18

12 Apr '18

#7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | 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: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7606#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted
by GHC 12 Apr '18

12 Apr '18

#13715: test dynamic-paper for way profasm fails with Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: simplifier | Operating System: Unknown/Multiple ticks | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: dynamic-paper | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- on ghc 8.2.1-rc2 on a mac running the latest Xcode and os {{{ make TEST=dynamic-paper WAY=profasm fails with ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone delta ... Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad it also fails with 1000 ticks make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick- factor=1000' so there may be an infinite loop -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15026: Type deduction panic
by GHC 11 Apr '18

11 Apr '18

#15026: Type deduction panic -------------------------------------+------------------------------------- Reporter: moomin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!lhs > {-# LANGUAGE DeriveFunctor #-} > module Bug where > import qualified Data.Set as S > import Data.Foldable (fold, foldMap, toList) > import Data.List.Split (splitOn) > import Data.Monoid -- ((<>), Sum, mempty, mappend) > import Data.Functor.Foldable > newtype Component = Component (Int,Int) deriving (Eq, Ord, Show) > data Day24State v a = Day24State { > valueToMatch :: Int, > componentsToUse :: S.Set Component, > componentMetric :: v, > nextStates :: [a] > } deriving (Functor, Show) > type Day24StateFix v a = Fix (Day24State v) }}} Now in GHCI type > :t Data.Functor.Foldable.ana f (undefined :: Day24StateFix Component) Produces ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] f_akbJ :: t_akbI[tau:3] (CHoleCan: f)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values
by GHC 10 Apr '18

10 Apr '18

#10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The LLVM sqrt intrinsic is undefined below values of -0.0 See http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined. This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen. {{{ main = print (sqrt (-7 :: Double)) }}} {{{ $ ghc -O -fllvm Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt 0.0 $ ghc -O Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt NaN }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
by GHC 10 Apr '18

10 Apr '18

#8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I get the following error... {{{ <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) }}} When running following program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import qualified Data.Text.IO as T main = T.putStrLn "čušpajž日本語" }}} Was tested in #haskell and I have all the UTF-8 Settings set and so forth. It compiles just fine, but crashes during runtime. gcc -v: {{{ Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.4/4.2.1/specs Target: amd64-unknown-openbsd5.4 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #4942: GHC.ConsoleHandler does not call back application when Close button is pressed
by GHC 10 Apr '18

10 Apr '18

#4942: GHC.ConsoleHandler does not call back application when Close button is pressed -------------------------------------+------------------------------------- Reporter: Amatic | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pdedecker): I have an console application that communicates with external hardware (scientific instruments). This hardware needs to be initialized at application start and cleanly shut down at application end, otherwise damage or increased wear can result. Unfortunately, many users close the program by hitting the "X" close button on the console window, even when trained not to. Years of routine are hard to beat. This bug prevents me from solving this, by making it impossible to run safely shut down the equipment in response to a close event. Please make it possible to handle these events and run cleanup code. Regarding the possibility of the Haskell code leading to an unkillable window: google suggests that the application will be terminated after a timeout, even if the handler function hasn't returned yet. So this may not be an issue in practice? (e.g. https://stackoverflow.com/questions/47041407/why-does-my-windows-console- close-event-handler-time-out) ALSO: the documentation for GHC.ConsoleHandler should reflect that Close events are ignored, which does not appear to be the case at present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4942#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0