November 2017 - ghc-tickets

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 30 Nov '17

30 Nov '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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 mpickering): I rebased the branch here - https://github.com/mpickering/ghc/tree/nested- cpr I get 7 test failures running in simpleCore. There is also a core lint error when running a fresh build. I put it up on phab as well for easier viewing. (https://phabricator.haskell.org/D4244) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14503: Killing a thread will block if there is another process reading from a handle
by GHC 30 Nov '17

30 Nov '17

#14503: Killing a thread will block if there is another process reading from a handle ----------------------------------------+--------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [https://github.com/capitanbatata/sandbox/tree/master/dangling-connections this sample code]. I'll explain the relevant details below. I have the following Haskell code: {{{#!hs someFuncWithChans :: IO () someFuncWithChans = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering ch <- newChan putStrLn "Starting the handler reader" readerTid <- forkIO $ handleReader h ch cmdsHandler h ch putStrLn "Killing the handler reader" killThread readerTid putStrLn "Closing the handle" hClose h cmdsHandler :: Handle -> Chan Action -> IO () cmdsHandler h ch = do act <- readChan ch case act of Quit -> putStrLn "Bye bye" Line line -> do hPutStrLn h (reverse line) cmdsHandler h ch handleReader :: Handle -> Chan Action -> IO () handleReader h ch = forever $ do line <- strip <$> hGetLine h case line of "quit" -> writeChan ch Quit _ -> writeChan ch (Line line) data Action = Quit | Line String }}} Is the function `someFuncWithChans` is run along with the following Java program, then the former will block while killing the handler reader (`readerTid`). {{{#!java public static void main(String[] args) throws IOException, InterruptedException { ServerSocket serverSock = new ServerSocket(9090); Socket sock = serverSock.accept(); InputStream inStream = sock.getInputStream(); BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream)); OutputStream outStream = sock.getOutputStream(); PrintWriter sockOut = new PrintWriter(new OutputStreamWriter(outStream)); while (true) { Thread.sleep(1000); System.out.println("Sending foo"); sockOut.println("foo"); sockOut.flush(); String s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending bar"); sockOut.println("bar"); sockOut.flush(); s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending quit"); sockOut.println("quit"); sockOut.flush(); // This will cause someFuncWithChans to block when killing the // reader thread. s = sockIn.readLine(); System.out.println("Got " + s ); } } }}} If the `sockIn.readLine()` is commented out, then killing the thread will succeed. This problem appears only on my Windows machine (at work), whereas it does not on my personal Linux machine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14528: LLVM's CallAnalyzer Breaks
by GHC 30 Nov '17

30 Nov '17

#14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (LLVM) | Keywords: inline | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: 11295 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found this issue while working on #11295. It seems that after first running `-mem2reg -inline` on some nofib programs, such as `imaginary/integrate` and `real/lift` (using `llvm-link` to roll the IR files together), running another pass that depends on LLVM's CallAnalyzer will cause `opt` to overflow the stack. For example, here are some pass sequences that break `opt` when optimizing `integrate`: * `-mem2reg -inline -gvn` * `-mem2reg -inline -instcombine` * `-mem2reg -inline -early-cse` This happens in LLVM 5 and tip-of-tree (LLVM 6). It probably is present in LLVM 4 as well. I'm working on putting together a reduced test case to report a bug to LLVM developers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 29 Nov '17

29 Nov '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) 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 mpickering): Did this patch ever get submitted? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14511: indexArray# getting poorly deferred
by GHC 29 Nov '17

29 Nov '17

#14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In both of the following functions I am attempting to execute a read from an `Array# a` and then write the result to a `MutableArray# s a`, and I would like the following evaluation properties: * the `a` value is not forced, i.e. the value stored in the `MutableArray# s a` will remain a thunk if the original value in the `Array# a` was; and * the new `MutableArray#` does not maintain any references to the original `Array#`, so that the original can be GCed. The singleton-unboxed-tuple return type of `indexArray#` appears to be there to allow specifically this use case, but sadly it only succeeds for the first of these functions. The second function ends up storing a thunk in the `MutableArray#` which contains a reference to the `Array#`. Haskell: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module IndexThenWrite where import GHC.Prim indexThenWrite :: Array# a -> MutableArray# s a -> State# s -> State# s indexThenWrite arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# a s indexThenWriteF :: (a -> b) -> Array# a -> MutableArray# s b -> State# s -> State# s indexThenWriteF f arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# (f a) s }}} Core: {{{#!hs -- RHS size: {terms: 15, types: 18, coercions: 0, joins: 0/0} indexThenWrite indexThenWrite = \ @ a_aq9 @ s_aqa arr_apa marr_apb s1_apc -> case indexArray# arr_apa 123# of { (# ipv_sUH #) -> writeArray# marr_apb 234# ipv_sUH s1_apc } -- RHS size: {terms: 18, types: 22, coercions: 0, joins: 0/0} indexThenWriteF indexThenWriteF = \ @ a_aq0 @ b_aq1 @ s_aq2 f_ape arr_apf marr_apg s1_aph -> writeArray# marr_apg 234# (case indexArray# arr_apf 123# of { (# ipv_sUK #) -> f_ape ipv_sUK }) s1_aph }}} I'd like the second function to generate code similar to the first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14454: Unregisterised build is broken
by GHC 29 Nov '17

29 Nov '17

#14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Fails with several errors along the lines of, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20171111 for x86_64-unknown-linux): pprCLbl AsmTempLabel Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Exception.o' failed make[1]: *** [rts/dist/build/Exception.o] Error 1 make[1]: *** Waiting for unfinished jobs.... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13941: STG linter's type equality can loop
by GHC 29 Nov '17

29 Nov '17

#13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- `stgEqType` will currently loop when given the following, {{{#!hs stgEqType (a -> IO ()) (a -> IO ()) }}} The problem is that the `(->)` tycon now takes runtime rep arguments. To see why, let's look at the (paraphrased) implementation, {{{#!hs stgEqType orig_ty1 orig_ty2 = gos (typePrimRep orig_ty1) (typePrimRep orig_ty2) where gos :: [PrimRep] -> [PrimRep] -> Bool gos [_] [_] = go orig_ty1 orig_ty2 gos reps1 reps2 = reps1 == reps2 go :: UnaryType -> UnaryType -> Bool go ty1 ty2 | Just (tc1, tc_args1) <- splitTyConApp_maybe ty1 , Just (tc2, tc_args2) <- splitTyConApp_maybe ty2 , let res = if tc1 == tc2 then equalLength tc_args1 tc_args2 && and (zipWith (gos `on` typePrimRep) tc_args1 tc_args2) else (isFamilyTyCon tc1 || isFamilyTyCon tc2) = res | otherwise = True -- Conservatively say "fine". }}} Our example will begin by looking at the `gos (typePrimRep orig_ty1) (typePrimRep orig_ty2)` and, seeing that the `orig_ty`s are unary, enter `go`. We will then split the applications such that, {{{ tc1, tc2 = (->) tc_args1, tc_args2 = ['LiftedPtrRep, 'LiftedPtrRep, a, IO ()] }}} Seeing that the tycons are equal, we will enter `gos` on each of the `tc_args`. Of course, one would think that `typePrimRep 'LiftedPtrRep` should throw an error, but because `gos` only forces the spine of the list, that error doesn't get thrown. Instead we incorrectly conclude that `'LiftedPtrRep` is a unary type and recurse into `go orig_ty1 orig_ty2`, thus looping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14117: stg-lint fails on unlifted-type join point binding
by GHC 29 Nov '17

29 Nov '17

#14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While validating GHC with `BuildFlavour=devel2` and `-dstg-lint` I found that the linter chokes when it finds a join point of unlifted type (like this one from the `Binary` module), {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [RHS of $j_sDSL :: (# State# RealWorld, () #)] Let(rec) binder ‘$j_sDSL’ has unlifted type ‘(# State# RealWorld, () #)’ RHS: \r [] src<compiler/utils/Binary.hs:516:9-17> src<compiler/utils/Binary.hs:(516,21)-(518,26)> src<compiler/utils/Binary.hs:260:1-45> src<compiler/utils/Binary.hs:(239,1)-(246,34)> case readIntArray# [ww_sDSF 0# w1_sDSJ] of { ... }}} If I'm not mistaken there is no problem with join points having unlifted type (see `Note [CoreSyn let/app invariant]`). We just need to update the STG linter appropriately. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14118: stg2stg passes appear to produce invalid STG
by GHC 29 Nov '17

29 Nov '17

#14118: stg2stg passes appear to produce invalid STG -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- While building with GHC with `-dstg-lint -g3 -O0` (after fixing #14116 and #14117) I encountered a rather peculiar error, {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id integer-gmp-1.0.1.0 -hide-all-packages -i -ilibraries/integer-gmp/src/ -ilibraries/integer-gmp/dist-install/build -Ilibraries/integer-gmp/dist-install/build -ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/dist- install/build/./autogen -Ilibraries/integer-gmp/include -optP-include -optPlibrari es/integer-gmp/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.1.0 -this-unit-id integer-gmp -Wall -XHaskell2010 -O -dcore- lint -g3 -ddump-to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lin t -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical- monad-instances -odir libraries/integer-gmp/dist-install/build -hidir libraries/integer-gmp/dist-install/build -stubdir libraries/intege r-gmp/dist-install/build -dynamic-too -c libraries/integer- gmp/src//GHC/Integer/Type.hs -o libraries/integer-gmp/dist- install/build/GHC/Integer/Type.o -dyno libraries/integer-gmp/dist- install/build/GHC/Integer /Type.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** <no location info>: warning: [in body of lambda with binders m0_scBy :: State# s_a2Em -> State# s_a2Em, s1_scBz :: State# s_a2Em] s'_scBA is out of scope <no location info>: warning: [in body of lambda with binders wild1_sdUv :: Int#] qr_sdUp is out of scope }}} Looking at the STG it appears that these warnings are absolutely correct, {{{#!hs svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (State# s -> State# s) -> S s () [GblId, Arity=2, Caf=NoCafRefs, Str=<C(S),1*C1(U)><S,U>, Unf=OtherCon []] = \r [m0_scBy s1_scBz] src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:1-48> case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src<libraries/integer- gmp/src/GHC/Integer/Type.hs:1957:37-48> (#,#) [s'_scBA ()]; }; }}} This is quite strange given that `s'_scBA` is clearly in scope, being bound as the case binder. We had the following from Core Prep, {{{#!hs -- RHS size: {terms: 10, types: 17, coercions: 0, joins: 0/0} GHC.Integer.Type.svoid [InlPrag=INLINE (sat-args=1)] :: forall s. (GHC.Prim.State# s -> GHC.Prim.State# s) -> GHC.Integer.Type.S s () [GblId, Arity=2, Caf=NoCafRefs, Str=<C(S),1*C1(U)><S,U>, Unf=OtherCon []] GHC.Integer.Type.svoid = \ (@ s_a2Em) (m0_scBy [Occ=Once!] :: GHC.Prim.State# s_a2Em -> GHC.Prim.State# s_a2Em) (s1_scBz [Occ=Once] :: GHC.Prim.State# s_a2Em) -> src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:1-48> case m0_scBy s1_scBz of s'_scBA { __DEFAULT -> src<libraries/integer-gmp/src/GHC/Integer/Type.hs:1957:37-48> (# s'_scBA, GHC.Tuple.() #) } }}} The reason the linter fails here is due to the following logic in `lintStgExpr`, {{{#!hs in_scope <- MaybeT $ liftM Just $ case alts_type of AlgAlt tc -> check_bndr (tyConPrimRep tc) >> return True PrimAlt rep -> check_bndr [rep] >> return True MultiValAlt _ -> return False -- Binder is always dead in this case PolyAlt -> return True MaybeT $ addInScopeVars [bndr | in_scope] $ lintStgAlts alts scrut_ty }}} In the `svoid` case above we hit `MultiValAlt` path, which causes us to ignore the case binder. The fact that we hit `MultiValAlt` at all is a bit surprising given that the result is not an unboxed sum or tuple. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14521: Infinite loop at runtime when a given function is not marked INLINE
by GHC 29 Nov '17

29 Nov '17

#14521: Infinite loop at runtime when a given function is not marked INLINE -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered, if the function `Animation.animate'` is not inlined. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb1… (to reproduce, shoot at a number in the game) The fix is the commit that follows : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e27… stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Thank you, Olivier -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14521> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23