October 2017 - ghc-tickets

[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

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

13 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 13 Jan '18

13 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

[GHC] #14182: Allow full control over dyn lib names
by GHC 11 Jan '18

11 Jan '18

#14182: Allow full control over dyn lib names -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.2.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: -------------------------------------+------------------------------------- This is related to: * GHC ticket #11587 * Cabal issue https://github.com/haskell/cabal/issues/4263 * Cabal PR https://github.com/haskell/cabal/pull/4656 * Cabal PR https://github.com/haskell/cabal/pull/4426 Currently GHC hard codes the naming convention for shared/dynamic libraries. For example: For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX). This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version. This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique. The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information. We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`. **So specifically:** * Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`. * When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used. While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra- ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14378: Unreasonably high memory use when compiling with profiling and -O2/-O2
by GHC 09 Jan '18

09 Jan '18

#14378: Unreasonably high memory use when compiling with profiling and -O2/-O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Based on [https://github.com/Daniel-Diaz/matrix/issues/43] I tried that myself. * Without profiling: <10 sec, <110M Residency * Profiling and -O: 90sec, 1.5GB Residency * Profiling and -O2: Killed it after 4 Minutes and it started swapping on a 16GB Ram machine. The invocation was: ghc Matrix.hs -prof -fprof-auto -c -fforce-recomp -O -v -fprof-auto-exported -caf-all -auto-all -fstatic-argument- transformation Numbers above from 8.0.2. 8.2.1 improved to slightly worse than -O1 with ~95 sec and ~2.5GB ram usage. Still seems like a bug though. I haven't tried HEAD yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14042: Data type with type family in return kind spuriously rejected
by GHC 07 Jan '18

07 Jan '18

#14042: Data type with type family in return kind spuriously rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This typechecks: {{{#!hs {-# LANGUAGE TypeInType #-} import Data.Kind type Id (a :: Type) = a data Foo :: Id Type }}} But changing the type synonym to a type family causes it to fail: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind type family Id (a :: Type) :: Type where Id a = a data Foo :: Id Type }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:9:1: error: • Kind signature on data type declaration has non-* return kind Id * • In the data declaration for ‘Foo’ | 9 | data Foo :: Id Type | ^^^^^^^^ }}} That error message is wrong, since `Id * = *`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10245: panic in new integer switch logic with "out-of-range" literals
by GHC 07 Jan '18

07 Jan '18

#10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this module {{{ module D (f) where f :: Int -> String f n = case n of 0x8000000000000000 -> "yes" _ -> "no" }}} crashes with the error {{{ [1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): Map.findMin: empty map has no minimal element }}} The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals. The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10731: System.IO.openTempFile is not thread safe on Windows
by GHC 04 Jan '18

04 Jan '18

#10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given the test program: {{{#!hs import Control.Concurrent import System.IO import Control.Monad import System.Directory main = do putStrLn "Starting" var <- newEmptyMVar tdir <- getTemporaryDirectory xs <- replicateM 10 $ do var <- newEmptyMVar flip forkFinally (\s -> do print s; putMVar var ()) $ do replicateM_ 100000 $ do (file, h) <- openTempFile tdir "test.txt" hClose h removeFile file return var mapM_ takeMVar xs }}} If I compile and run that with {{{ghc --make TmpFile.hs -threaded && tmpfile +RTS -N5}}} I get: {{{ Starting Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) Left C:\Users\NDMIT_~1\AppData\Local\Temp\: openTempFile: permission denied (Permission denied) ... }}} I've reproduced this on GHC 7.8 and 7.10.1. We hit this in production about twice a day. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE
by GHC 02 Jan '18

02 Jan '18

#12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: performance, | Operating System: Unknown/Multiple inline, bits | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given that they are fairly essential operations in core libraries such as containers, I think it would be useful to have them marked as INLINE (or INLINABLE at the very least). See also: https://github.com/haskell/containers/pull/216 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13201: Type-level naturals aren't instantiate with GHCi debugger
by GHC 02 Jan '18

02 Jan '18

#13201: Type-level naturals aren't instantiate with GHCi debugger -------------------------------------+------------------------------------- Reporter: konn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- GHCi debugger cannot use the information of specific value type-level natural number, even if it is explicitly specified. For example, consider the following code: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, StandaloneDeriving, TypeOperators #-} module Main where import GHC.TypeLits data Foo (n :: Nat) = Foo deriving instance KnownNat n => Show (Foo n) fooSucc :: Foo n -> Foo (n + 1) fooSucc Foo = Foo foos :: Foo n -> [Foo (n + 1)] foos f = loop 5 where loop 0 = [] loop n = fooSucc f : loop (n - 1) main :: IO () main = print $ foos (Foo :: Foo 5) }}} Loading it with GHCi Debugger, we cannot `show` the value of `f`, because GHCi debugger doesn't know the specific value of `n` (in`Foo n`), even though we specify it in `main`! {{{#!hs ghci> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) Ok, modules loaded: Main. ghci> :break foos Breakpoint 0 activated at tmp.hs:13:10-15 ghci> :set stop :list ghci> main Stopped in Main.foos, tmp.hs:13:10-15 _result :: [Foo (n + 1)] = _ loop :: (Num t, Eq t) => t -> [Foo (n + 1)] = _ 12 foos :: Foo n -> [Foo (n + 1)] 13 foos f = loop 5 14 where ghci> :step Stopped in Main.foos.loop, tmp.hs:16:14-37 _result :: [Foo (n + 1)] = _ f :: Foo n = _ n :: Integer = 5 15 loop 0 = [] 16 loop n = fooSucc f : loop (n - 1) 17 ghci> :t f f :: Foo n ghci> f <interactive>:8:1: error: • No instance for (KnownNat n) arising from a use of ‘print’ • In a stmt of an interactive GHCi command: print it }}} Of course, we can inspect the internal representation via `:print` or `:force` command, but it is rather impractical when we cannot easily read its pretty form from its internal representation . I tested this with GHC 7.0.1 and 7.0.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5