January 2018 - ghc-tickets

[GHC] #14650: Panic with no extensions (StgCmmEnv: variable not found)
by GHC 15 Jan '18

15 Jan '18

#14650: Panic with no extensions (StgCmmEnv: variable not found) -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I compile the attached Haskell program with `-O2`, or `-O1` with `-fspec-constr` added, I get a compiler panic: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-mingw32): StgCmmEnv: variable not found $smergeSplit_s3bq local binds for: $WLL $W:% $W:& cmp_s3ox eta_s3oy $wmergeLL_s3oz $s$wpush_s3pZ $wpush_s3q0 $s$wmergeAll_s3rl $wmergeAll_s3rR $wsplitDesc_s3sp $wsplitAsc_s3sC mergeSplit_s3tt ss_s3tu ds_s3tv wild_s3tw a1_s3tC as'_s3tD wild1_s3tE b_s3tF bs_s3tG wild2_s3tH ww1_s3tJ ww2_s3tK ww3_s3tL ww4_s3tM ww6_s3tO ww7_s3tP ww8_s3tQ ww9_s3tR Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\codeGen\StgCmmEnv.hs:147:9 in ghc:StgCmmEnv }}} I ran it with `-dcore-lint`, and it gives the following messages (full .lint attached): {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: jump $smergeSplit_s3bN ww_s34F ww_s34Q ww_s34R ww_s34S ww_s34T $smergeSplit_s3bN [Occ=LoopBreaker] :: [a_a23n] -> Int# -> Bool -> [a_a23n] -> Stack a_a23n -> [a_a23n] [LclId[JoinId(5)], Arity=5, Str=<S,U><L,U><L,U><L,U><L,U>, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [80 0 0 0 0] 554 0}] is out of scope <no location info>: warning: In the expression: jump $smergeSplit_s3bN ww_s34F ww_s34Q ww_s34R ww_s34S ww_s34T Invalid occurrence of a join variable: $smergeSplit_s3bN The binder is either not a join point, or not valid here <no location info>: warning: In the expression: jump $smergeSplit_s3bN ww_s34K ww_s34Q ww_s34R ww_s34S ww_s34T $smergeSplit_s3bN [Occ=LoopBreaker] :: [a_a23n] -> Int# -> Bool -> [a_a23n] -> Stack a_a23n -> [a_a23n] [LclId[JoinId(5)], Arity=5, Str=<S,U><L,U><L,U><L,U><L,U>, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [80 0 0 0 0] 554 0}] is out of scope <no location info>: warning: In the expression: jump $smergeSplit_s3bN ww_s34K ww_s34Q ww_s34R ww_s34S ww_s34T Invalid occurrence of a join variable: $smergeSplit_s3bN The binder is either not a join point, or not valid here }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14632: Export typeNatDivTyCon from TcTypeNats
by GHC 15 Jan '18

15 Jan '18

#14632: Export typeNatDivTyCon from TcTypeNats -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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: -------------------------------------+------------------------------------- TcTypeNats exports the TyCons for all type-level natural operations, except: - typeNatDivTyCon - typeNatModTyCon - typeNatLogTyCon Could these be exported as well so I dont need ugly code like https://github.com/clash-lang/ghc-typelits- extra/blob/b46074169205945cc0ff822669436ed0b4a83c41/src/GHC/TypeLits/Extra/Solver.hs#L169-L170 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14632> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13752: Odd pattern synonym type errors
by GHC 14 Jan '18

14 Jan '18

#13752: Odd pattern synonym type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose we have {{{#!hs newtype Arrange = Arrange {getArrange :: [Int] -> [Int]} }}} If I write {{{#!hs pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- Arrange f }}} I get {{{ • Couldn't match type ‘[Int] -> [Int]’ with ‘forall a. Int ~ a => [a] -> [a]’ Expected type: forall a. c a => [a] -> [a] Actual type: [Int] -> [Int] • In the declaration for pattern synonym ‘Heh’ }}} It surprises me that these don't match. I can hack around that a bit: {{{#!hs newtype Help = Help {getHelp :: forall a. Int ~ a => [a] -> [a]} pattern Heh :: (c ~ ((~) Int)) => (forall a. c a => [a] -> [a]) -> Arrange pattern Heh f <- ((\x -> Help (getArrange x)) -> Help f) }}} Now this compiles, and I can use it in a variety of ways, but not quite all. If I write {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- Heh f }}} I get {{{ Haha.hs:78:23: error: • Couldn't match expected type ‘[Int] -> [Int]’ with actual type ‘forall a. Int ~ a => [a] -> [a]’ • In the declaration for pattern synonym ‘Heh'’ | 78 | pattern Heh' f <- Heh f | ^ }}} This strikes me as perhaps even more surprising. I can hack around that too, of course, but yuck! {{{#!hs pattern Heh' :: ([Int] -> [Int]) -> Arrange pattern Heh' f <- ((\(Heh g) -> g @ Int) -> f) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10634: Type class with bijective type functions
by GHC 14 Jan '18

14 Jan '18

#10634: Type class with bijective type functions -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- See the attached module. {{{ $ cat TypeFunctionBijection.hs {-# LANGUAGE TypeFamilies #-} module TypeFunctionBijection where import Data.Int (Int8, Int16, Int32) type family Up a type instance Up Int8 = Int16 type instance Up Int16 = Int32 class (Up (Down a) ~ a) => Convert a where type Down a down :: a -> Down a instance Convert Int16 where type Down Int16 = Int8 down = fromIntegral instance Convert Int32 where type Down Int32 = Int16 down = fromIntegral x :: Int8 x = down 8 }}} {{{ $ ghci-7.8.4 -Wall TypeFunctionBijection.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) Ok, modules loaded: TypeFunctionBijection. *TypeFunctionBijection> :q Leaving GHCi. }}} {{{ $ ghci-7.10.1 -Wall TypeFunctionBijection.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling TypeFunctionBijection ( TypeFunctionBijection.hs, interpreted ) TypeFunctionBijection.hs:24:5: Couldn't match expected type ‘Int8’ with actual type ‘Down a0’ The type variable ‘a0’ is ambiguous In the expression: down 8 In an equation for ‘x’: x = down 8 Failed, modules loaded: none. Prelude> :q Leaving GHCi. }}} Up to GHC-7.8.4 I could make a type function like `Down` a bijection by adding equality constraints to the `Convert` class. In GHC-7.10.1 this fails. Is this a bug or a feature? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 14 Jan '18

14 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think we all agree that the simplifier is not at fault here. Indeed the approach that duog mentions comment:25 is roughly what osa1 and I have discussed. However, it's slightly tricky as unfoldings are currently dropped before we make it to `core2Stg` (in CorePrep). I doubt this will unacceptably increase the number of emitted cost centers although I've been wrong before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13903: KQueue evtmgr backend fails to register for write events
by GHC 14 Jan '18

14 Jan '18

#13903: KQueue evtmgr backend fails to register for write events -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: FreeBSD Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The root of the problem is that the `GHC.Event.KQueue.toFilter` function has type `GHC.Event.Internal.Event -> Filter` with GHC's `Event` being a bitmask which can represent read events, write events or a combination of those. It happens that the event manager requests it's backend to be notified about read ''and'' write events on some fd, and because the kqueue `EVFILT_*`s are ''not'' bitmasks, the above function cannot capture this, silently dropping the desire to be notified about write events. The following program triggers the problematic behaviour: {{{ import Control.Concurrent ( forkIO, killThread ) import Control.Exception ( finally ) import Control.Monad.Trans.Resource ( runResourceT ) import Control.Monad.IO.Class ( liftIO ) import qualified Data.ByteString as BS import Data.Conduit ( ($$), ($=) ) import qualified Data.Conduit.Binary as CB import qualified Data.Conduit.List as CL import qualified Data.Conduit.Network as CN import Data.IORef ( newIORef, modifyIORef', readIORef) main :: IO () main = CN.runTCPClient (CN.clientSettings 5555 "192.168.2.11") client where logMsg cnt = CL.mapM $ \bs -> liftIO $ do modifyIORef' cnt (+ 1) readIORef cnt >>= \x -> putStrLn $ "msg #" ++ show x ++ " of size: " ++ show (BS.length bs) return bs client ad = do reader <- forkIO (runResourceT $ CN.appSource ad $$ CL.mapM_ ( \bs -> (liftIO . putStrLn) $ "read " ++ show (BS.length bs) ++ " bytes")) cnt <- newIORef ( 0 :: Int ) let runPipe = runResourceT $ CB.sourceFile "cool-linux-distro.iso" $$ logMsg cnt $= CN.appSink ad runPipe `finally` (killThread reader) }}} Having a `nc -l -p 5555 > /dev/null` running on another machine is sufficient to sink the data. Assuming that we can read `bigfile.iso` faster than we can send out over the socket, the `send` syscall will at some point give an `EAGAIN` as can be seen in the `truss` output: {{{ write(1,"msg #20 of size: 32752\n",23) = 23 (0x17) sendto(12,"\f\2409\0\M^RA\^T\M-&A\M-'\M-d8"...,32752,0x0,NULL,0x0) = 32752 (0x7ff0) read(13,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752) = 32752 (0x7ff0) poll({ 1/POLLOUT },1,0) = 1 (0x1) msg #21 of size: 32752 write(1,"msg #21 of size: 32752\n",23) = 23 (0x17) sendto(12,"\M^?\0'\\\M-B\M-:+\^]D\M-0\M-="...,32752,0x0,NULL,0x0) = 19204 (0x4b04) sendto(12,"\M-j$2\M^BH\M-#-\^A\M-E\^O\M^Y\a"...,13548,0x0,NULL,0x0) ERR#35 'Resource temporarily unavailable' SIGNAL 26 (SIGVTALRM) sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0) sigreturn(0x7fffffff9c60) ERR#35 'Resource temporarily unavailable' kevent(3,{ 12,EVFILT_READ,EV_ADD|EV_ONESHOT,0x0,0x0,0x0 },1,0x0,0,{ 0.000000000 }) = 0 (0x0) _umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 26 (SIGVTALRM) sigprocmask(SIG_SETMASK,{ SIGVTALRM },0x0) = 0 (0x0) sigreturn(0x7fffffffdc00) ERR#4 'Interrupted system call' _umtx_op(0x800c71ed0,UMTX_OP_WAIT_UINT_PRIVATE,0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 26 (SIGVTALRM) }}} Not the `sendto` call on fd 12 resulting in `ERR#35`, soon followed by an `kevent` call for that same fd and only `EVFILT_READ` set. This makes little sense as it was an attempt to ''write'' that just failed. This is caused by `toFilter` giving precedence to `read` events, dropping the write event. Not starting the `reader` thread prevents bad things from happening as then the `write` events are properly passed thru to kqueue. I have an initial version of a patch fixing this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code
by GHC 14 Jan '18

14 Jan '18

#13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Currently, it is very difficult to use the MySQL/MariaDB client library with Haskell. One must use bound threads, which comes at a performance penalty. The reason is that the underlying library requires a certain initialization function to be called on each OS thread before any other functions are called. Similarly, it is difficult to optimally use libcurl with GHC. The best- performing way to use libcurl is to have one multi handle per thread and to use `curl_multi_socket_action` to respond to events. This is currently not possible from Haskell, at least not easily. (There are other issues with using libcurl from Haskell; most notably libcurl’s event support makes heavy use of callbacks, which are slow, to tell the application which file descriptors to wait for. But that is a separate issue.) Setting milestone to 8.4.1 because I don’t think that this is difficult. This is a feature requ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:26 osa1]: > > My current understanding is now that the cost-centres are, modulo bugs, removed when they aren't wrapping any work. I don't think we have any examples here of erroneous cost-centre removal, do you agree? > > Well, this ticket iself is an example of erroneous cost-centre removal, isn't it? To be more precise, I claim that there are no simplifier bugs here; all of the `scc`s that are removed (by the simplifier) in the examples above are ok to remove. If you disagree, can you point to one above? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14666: Improve assembly for dense jump tables.
by GHC 13 Jan '18

13 Jan '18

#14666: Improve assembly for dense jump tables. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: Cmm, Asm, | Operating System: Unknown/Multiple CodeGen | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When generating assembly for cases with dense alternatives GHC currently often generates somewhat repetitive code: {{{ Main.$wf_test_info: ... # Check range _u48M: #Jump into jump table jmp *_n48P(,%r14,8) _c48H: movl $11008,%ebx jmp *(%rbp) ##################### # Repeat 6 more times ##################### _c48A: movl $11001,%ebx jmp *(%rbp) _c48z: movq $-1,%rbx jmp *(%rbp) _n48P: #Jump table }}} From what I've seen it should often be possible to replace the indirect jmp with a indirect mov instead. {{{ ... #Check Range .Lu48M: #Get value out of table and jump to continuation. movl .Ln48P(,%r14,8), %ebx jmp *(%rbp) .Lc48z: movq $-1,%rbx jmp *(%rbp) .Ln48P: #Jump table }}} Depending on the number of cases this has the potential to do a lot for code size. ---- I did the transformation manually for one case in a inner loop. It improved speed but not much and depending on the codelayout I did it was possible to get worse performance in specific cases. It's also not a simply patch as Cmm currently generates switches containing gotos. So this would require a change in the Cmm stage as well as in the code generator. But it should be at least worth investigating and seems to be what gcc does for similar cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Jan '18

13 Jan '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > My current understanding is now that the cost-centres are, modulo bugs, removed when they aren't wrapping any work. I don't think we have any examples here of erroneous cost-centre removal, do you agree? Well, this ticket iself is an example of erroneous cost-centre removal, isn't it? I don't know answers to other questions, but I think the right thing to do here is to collect cost-centers in Core instead of STG (maybe in coreToStg). Because unfoldings are just Core expressions, once we have the code for collecting cost centers from unfoldings we can just use the same function for the actual program so no need for two functions for collecting cost centers (one collects from Core, another one from STG). So once we write this we can get rid of cost center collection in STG, `stgMassageForProfiling` would just add CAF cost centers. On a related note, I found this in the user manual: (8.1.1) > Cost centres are just program annotations. When you say -fprof-auto to the compiler, it automatically inserts a cost centre annotation around every binding not marked INLINE in your program, but you are entirely free to add cost centre annotations yourself. So GHC by default avoids this bug by not adding SCCs to INLINE functions but if you do it yourself you get this bug in some cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0