- ghc-tickets - Haskell.org

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 07 Dec '18

07 Dec '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15525 | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I'm going to punt this to 8.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16005: Don't use a generic apply thunk for known calls
by GHC 07 Dec '18

07 Dec '18

#16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5414 | Wiki Page: -------------------------------------+------------------------------------- Currently, an AP thunk like `sat = f a b c` will not have its own entry point and info pointer and will instead reuse a generic apply thunk like `stg_ap_4_upd`. That's great from a code size perspective, but if `f` is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch. ---- I prepared a patch over at Phab:D5414 that fixes this by checking if the arity of `f` is unknown (e.g. 0). If not, it will no longer delegate to a generic apply thunk and generate regular entry code and info tables instead. No impact on allocations, but on counted instructions and code size. Significant changes to counted instructions: ||cryptarithm1 || -2.5%|| ||lcss || -2.3%|| ||paraffins || -3.8%|| ||wheel-sieve2 || -3.4%|| |||||| ||Min || -3.8%|| ||Max || +0.0%|| || Geometric Mean || -0.2%|| And changes to binary size greater than 0.1% (all the other programs, basically): || Program ||Size || Instrs|| || anna ||+0.3% ||-0.2%|| || expert ||+0.2% ||-0.0%|| || fluid ||+0.2% ||-0.1%|| || grep ||+0.2% ||-0.0%|| || infer ||+0.2% ||-0.4%|| || last-piece ||+0.2% ||-0.1%|| || lift ||+0.2% ||-0.0%|| || paraffins ||+0.2% ||-3.8%|| || prolog ||+0.2% ||-0.1%|| || scs ||+0.3% ||-0.0%|| || transform ||+0.2% ||-0.2%|| || veritas ||+0.2% ||+0.0%|| |||||||| || Min ||+0.1% ||-3.8%|| || Max ||+0.3% ||+0.0%|| || Geometric Mean ||+0.1% ||-0.2%|| -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity
by GHC 07 Dec '18

07 Dec '18

#15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This bug report is about the incorrect result not the poor performance.) Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64): {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e100000000 :: Double Infinity (5.70 secs, 68,552 bytes) Prelude> 1e1000000000 :: Double 0.0 (69.35 secs, 60,088 bytes) }}} Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases. More precisely, {{{ Prelude> 1e646457008 :: Double Infinity (40.80 secs, 64,272 bytes) Prelude> 1e646457009 :: Double 0.0 (40.46 secs, 60,088 bytes) }}} Note: {{{#!hs (floor $ 2^31 / logBase 2 10 + 16) == 646457009 }}} This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?). Standalone test program: {{{#!hs main = do print 1e646457008 print 1e646457009 }}} Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help). {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e646457008 :: Double Infinity (415.26 secs, 17,908 bytes) Prelude> 1e646457009 :: Double Infinity (417.66 secs, 17,820 bytes) Prelude> 1e746457298 :: Double Infinity (490.00 secs, 17,820 bytes) Prelude> 1e1000000000 :: Double GNU MP: Cannot allocate memory (size=419438600) Aborted $ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows
by GHC 07 Dec '18

07 Dec '18

#15894: Cannot find symbol during interactive linking using new-repl on Windows --------------------------------------+---------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- Originally from https://github.com/haskell/cabal/issues/5683. I get the following error on Windows 10: {{{ > cabal new-repl --build-depends=ieee754 ... GHCi loads ... Prelude> import Numeric.IEEE Prelude Numeric.IEEE> infinity ghc.exe: | C:\Users\Anthony\AppData\Roaming\cabal\store\ghc-8.6.2\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\lib\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign' ghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} This occurs with both cabal-install 2.4.0.0 and HEAD. This does not occur if I install ieee754 into a sandbox and use `cabal repl`. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15866: libiserv's version number is hard-coded
by GHC 07 Dec '18

07 Dec '18

#15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` directly in its `.cabal` file. Needless to say, this is quite easy to forget to update. Let's let `autoconf` do the hard work for us and use `@ProjectVersionMunged@` instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15996: Add Unlifted List type to base
by GHC 06 Dec '18

06 Dec '18

#15996: Add Unlifted List type to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a }}} This would guarantee that values stored inside the list would not be thunks. It would likely live in something like GHC.List.Unlifted, since it uses GHC-specific things. An example of something it might improve is the implementation of Control.Concurrent.QSem.QSem: {{{#!hs data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} this could instead be: {{{#!hs type MVarIO = MVar# RealWorld -- type synonym for brevity data QSem = QSem (MVarIO (Int, UList (MVarIO ()), UList (MVarIO ()))) }}} Note that in this example the tuple inside the outermost `MVarIO` boxes the `Int` - this tuple could be represented as a datatype which ensures the unboxing on the `Int`. The main idea here though is that now you can use `MVar#` inside of the `UList`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15998: GHC.Event.Thread.eventManager has a lot of indirections
by GHC 06 Dec '18

06 Dec '18

#15998: GHC.Event.Thread.eventManager has a lot of indirections -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.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: -------------------------------------+------------------------------------- Current `eventManager`: {{{#!hs eventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager))) eventManager = unsafePerformIO $ do ... }}} That's a lot of indirections just to grab your thread's event manager. Consider the following, which I believe would improve the performance of this: {{{#!hs data UnliftedIORef :: TYPE 'UnliftedRep -> Type where UnliftedIORef :: MutVar# RealWorld a -> UnliftedIORef a eventManager :: UnliftedIORef (MutableArray# RealWorld Things) data Things = Things !ThreadId !EventManager }}} I think the Maybe can be eliminated. I'm unsure. What makes me think it can be is the following snippet: {{{#!hs getSystemEventManager :: IO (Maybe EventManager) getSystemEventManager = do t <- myThreadId (cap, _) <- threadCapability t eventManagerArray <- readIORef eventManager mmgr <- readIOArray eventManagerArray cap return $ fmap snd mmgr getSystemEventManager_ :: IO EventManager getSystemEventManager_ = do Just mgr <- getSystemEventManager return mgr {-# INLINE getSystemEventManager_ #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15998> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64
by GHC 06 Dec '18

06 Dec '18

#15780: ghc-8.4.4 failed to build on armv7 and aarch64 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit). https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522 They both fail in the same way: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4 for aarch64-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13104: runRW# ruins join points
by GHC 06 Dec '18

06 Dec '18

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Found this while poking around in the example for #12781. Suppose we have code like this: {{{ let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n = ... loop (n+1) {- tail call -} ... in runRW# @ 'PtrRepLifted @ Int (loop 0) }}} We would love for `loop` to be a join point, but it can't be because it's invoked in the argument to `runRW#`. In this situation, we're often rescued by Float In, which we might hope to give us this: {{{ runRW# @ 'PtrRepLifted @ Int ( let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 ) }}} Two problems: 1. Float In won't do this to begin with because `loop 0` is a partial application. 2. It's still not eligible to be a join point, again because `loop 0` is a partial application. What we would //like// to see is this: {{{ runRW# @ 'PtrRepLifted @ Int ( \s0 -> let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 s0 ) }}} Now we're golden. But someone has to have thought to eta-expand the argument to `runRW#` first. (Float In should then float `loop` into the lambda because, due to the state hack, the lambda is considered one-shot.) Perhaps the simplifier should //always// eta-expand the argument to `runRW#`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14847: Inferring dependent kinds for non-recursive types
by GHC 06 Dec '18

06 Dec '18

#14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType | 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 {{{ data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) }}} which is discussed in [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a corner of the user manual]. Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't. Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple. Warning: is this recursive? {{{ data Proxy2 k a where MkP :: Proxy k a -> Proxy2 k a }}} Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought. Similar questions for {{{ data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6