October 2016 - ghc-tickets

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 24 Oct '16

24 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: maurerl@… (added) Comment: Let's do (1); it's nearly ready! Akio, Luke (now in cc), can you work together on this? Luke has a pretty stable join-point branch which never destroys join points. Best just to build on that I think. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12756: ghci gives stg_ap_v_ret error
by GHC 24 Oct '16

24 Oct '16

#12756: ghci gives stg_ap_v_ret error --------------------------------------+---------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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: --------------------------------------+---------------------------------- The following interaction with ghci occurs: {{{ Prelude> :l Test.hs [1 of 2] Compiling BigWord ( lib/BigWord.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: BigWord, Main. *Main> main <interactive>: internal error: stg_ap_v_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} whereas the compiled file Test.hs executes without error. See the attached files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 24 Oct '16

24 Oct '16

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Regarding `wave4main`, the main problem seems to be destruction of a join point. The program contains an expression that looks like this: {{{ #!haskell runRW# (\ s -> letrec go s1 = let ... in (# s2, Array a b c #) in go s) }}} After a nested CPR transformation, it becomes: {{{#!haskell runRW# (\ s -> letrec $wgo s1 = let ... in (# s2, a, b, c #) in case $wgo s of (# s3, a', b', c' #) -> (# s3, Array a' b' c' #)) }}} destroying the join-point property of `go`. This is basically the same as what @nomeata found 2 years ago. I see two ways to move forward: 1. Wait for SequentCore to be implemented. 2. Have special cases for `runRW#` in the CPR analyzer and in the simplifier, as discussed in https://ghc.haskell.org/trac/ghc/ticket/10678#comment:10 I'm mildly interested in doing (2), but I don't think I fully understand the idea. In particular, the above comment mentions an example expression `case (runRW e) of BN# farr -> farr` that the simplifier would be able to transform. However, since `runRW#` returns an unboxed pair rather than a single boxed value, it seems that it would have to spot a much more complicated pattern to accomplish this transformation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12729: Unlifted newtypes via GADTSyntax
by GHC 22 Oct '16

22 Oct '16

#12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC disallows to define a newtype of an unlifted type (`newtype A = A Int#`). However, this restriction is not enforced when the newtype is defined using GADT syntax: {{{ newtype A where A :: Int# -> A }}} For example, I can derive Show for A and on my machine `main = print (A 0#)` segfaults. Tested on GHC 8.0.1 and master. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12729> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12752: GHC should be able to warn on usafe CPP usage
by GHC 22 Oct '16

22 Oct '16

#12752: GHC should be able to warn on usafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GCC has a warning `-Wundef` that catches unsafe CPP usage like: {{{#!c #if variable_does_not_exist // something #endif }}} The GCC man page says about `-Wundef`: {{{ -Wundef Warn if an undefined identifier is evaluated in an "#if" directive. }}} Following GCC's lead, GHC should have a similar warning flag to detect and warn about this problem in Haskell code that uses CPP. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12741: --numa doesn't work even if libnuma is available
by GHC 22 Oct '16

22 Oct '16

#12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.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: -------------------------------------+------------------------------------- The configure script set USE_LIBNUMA to 1 if numa exists however the code checks for HAVE_LIBNUMA. From the main directory, {{{ ./configure && make clean && make boot && make cd nofib/parallel/queens ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded ./Main 15 +RTS -N24 -s -A64m --numa }}} It fails saying {{{ Main: --numa: OS reports NUMA is not available }}} https://phabricator.haskell.org/D2329 introduced this error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12751: T5611 fails non-deterministically on OSX
by GHC 22 Oct '16

22 Oct '16

#12751: T5611 fails non-deterministically on OSX -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Here is the test. {{{#!hs {-# LANGUAGE CPP,ForeignFunctionInterface #-} import Control.Concurrent import Foreign.C import System.IO #ifdef mingw32_HOST_OS sleep n = sleepBlock (n*1000) foreign import stdcall unsafe "Sleep" sleepBlock :: Int -> IO () #else sleep n = sleepBlock n foreign import ccall unsafe "sleep" sleepBlock :: Int -> IO () #endif main :: IO () main = do hSetBuffering stdout LineBuffering tid <- forkIO $ do putStrLn "child: Sleeping" _ <- sleep 1 -- The following lines should not happen after the killThread from the -- parent thread completes. However, they do... -- putStrLn "child: Done sleeping" threadDelay 100000 putStrLn "child: Done waiting" threadDelay 100000 -- putStrLn $ "parent: Throwing exception to thread " ++ show tid throwTo tid $ userError "Exception delivered successfully" putStrLn "parent: Done throwing exception" threadDelay 200000 }}} It occasionally fails with {{{ =====> T5611(normal) 1 of 1 [0, 0, 0] cd "./concurrent/should_run/T5611.run" && "/Users/matt/Documents/haskell/ghc/inplace/test spaces/ghc-stage2" -o T5611 T5611.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -dno-debug-output cd "./concurrent/should_run/T5611.run" && ./T5611 Actual stderr output differs from expected: --- ./concurrent/should_run/T5611.run/T5611.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 +++ ./concurrent/should_run/T5611.run/T5611.run.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) *** unexpected failure for T5611(normal) Unexpected results from: TEST="T5611" }}} I am marking it broken for now. Does anyone know why it is failing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5030: Slow type checking of type-level computation heavy code.
by GHC 21 Oct '16

21 Oct '16

#5030: Slow type checking of type-level computation heavy code. -------------------------------------------------+----------------------- Reporter: thesz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler (Type checker) | Version: 7.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time performance bug | Test Case: T5030 Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+----------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5030#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12724: Be lazier about reducing type-function applications
by GHC 21 Oct '16

21 Oct '16

#12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider this: {{{ f :: F 20 -> F 20 f x = x }}} That ought to typecheck in a trice, right? But if `F` is a type function, GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F 20` unltimately reduces to `Int`, after a long time. Then we get {{{ f = \x . (x |> g1) |> g2 where g1 :: F 20 ~ Int g2 :: Int ~ F 20 }}} Here both `g1` and `g2` are big coercions. So we waste time reducing `F 20` ''and'' we generate giant coercions by doing so. Maybe the optimiser gets rid of them again; more probably not. But it's clearly stupid. This is one reason that the program in #5030 typechecks so slowly. We have {{{ cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU) cnst x = Left (Const x) }}} and there is absolutely no need to reduce either argument of the `Either` to normal form. Richard and I have ideas about how to fix this, but I'm recording it in a ticket. and -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3064: Very long compile times with type functions
by GHC 21 Oct '16

21 Oct '16

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0