August 2017 - ghc-tickets

[GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms
by GHC 28 Sep '17

28 Sep '17

#13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) 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: #8684, #12912 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From my discovery at https://phabricator.haskell.org/D42#30542: {{{ Why does the existing code work on platforms that are not Linux? In my select man page it says: On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 per‐ mits either behavior.) This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for multiple select()s in a loop without reinitializing it. Consider timeout to be undefined after select() returns. The existing select loop seems to rely on the fact that &tv is updated as described here. }}} Same for `man 2 poll`. E.g. `man 2 select` on FreeBSD 11 says explicitly: {{{ BUGS Version 2 of the Single UNIX Specification (``SUSv2'') allows systems to modify the original timeout in place. Thus, it is unwise to assume that the timeout value will be unmodified by the select() system call. FreeBSD does not modify the return value, which can cause problems for applications ported from other systems. }}} I have tested this now on FreeBSD, and indeed it doesn't work as expected. With GHC 7.10.2: {{{ import System.IO main = hWaitForInput stdin (1 * 1000) }}} `ghc --make test.hs -rtsopts` {{{ [root@ ~]# time ./test real 0m1.386s user 0m0.004s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.01 real 0m1.386s user 0m0.001s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.001 real 0m1.678s user 0m0.003s sys 0m0.002s [root@ ~]# time ./test +RTS -V0.0001 real 0m11.311s user 0m0.032s sys 0m0.139s }}} See how when we increase the timer signal, the sleep suddenly takes 10x longer than it should. That's because it triggers the case where EINTR is received in https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E…, letting us use the same unmodified 1-second `struct timeval *timeout` again and again. This demo of the bug works for GHC 7.10 and 8.0.1; in 8.0.2 `hWaitForInput` is broken (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4) so the demo doesn't work there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #13966: Missed optimization - loop fusion
by GHC 28 Sep '17

28 Sep '17

#13966: Missed optimization - loop fusion -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1-rc3 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: -------------------------------------+------------------------------------- I think GHC should be able to optimize func1 into func2, but currently it doesn't. {{{#!hs data Step s a = Done | Yield s a func1 high = loop1 0# 1# where loop1 acc i = case loop2 i of Done -> acc Yield (I# i') (I# x) -> loop1 (acc +# x) i' loop2 i = case tagToEnum# (i ># high) :: Bool of False -> case remInt# i 2# of 0# -> Yield (I# (i +# 1#)) (I# i) _ -> loop2 (i +# 1#) True -> Done func2 high = loop1 0# 1# where loop1 acc i = case tagToEnum# (i ># high) :: Bool of False -> case remInt# i 2# of 0# -> loop1 (acc +# i) (i +# 1#) _ -> loop1 acc (i +# 1#) True -> acc }}} When using the LLVM backend func2 is almost 4x faster than func1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11342: Character kind
by GHC 28 Sep '17

28 Sep '17

#11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- We know and love the Symbol kind, but as far as I know it's not possible to analyse a Symbol type, as we would a String term. It would be nice to have a Character kind and some related type families: {{{#!hs data Character -- Pattern match a Symbol. 'Nothing when empty, 'Just '(head, tail) -- otherwise. type family UnconsSymbol (s :: Symbol) :: Maybe (Character, Symbol) -- Put a Character at the head of a Symbol. type family ConsSymbol (c :: Character) (s :: Symbol) :: Symbol -- Work with Characters. Ideally we'd have counterparts for every -- function on Data.Char. type family ToUpper (c :: Character) :: Character type family IsAlpha (c :: Character) :: Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12376: Allow function definitions in record syntax
by GHC 27 Sep '17

27 Sep '17

#12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Would it be possible to write {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP = \k -> return $ maybe v id (Map.lookup k m) , putP = \k v' -> return $ go v (Map.insert k v' m) } }}} as {{{#!hs propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap { getP k = return $ maybe v id (Map.lookup k m) , putP k v' = return $ go v (Map.insert k v' m) } }}} Simpler example `MkFoo { id = \x -> x }` as {{{#!hs MkFoo { id x = x } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9898: Couldn't match type `(Char, ())' with `()'
by GHC 27 Sep '17

27 Sep '17

#9898: Couldn't match type `(Char, ())' with `()' -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Windows Keywords: | Type of failure: GHC Architecture: x86_64 (amd64) | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- 'test3' is expected to type check given that 'test1' and 'test2' type check. 'test4' is not expected to type check. {{{ ghc_bug2.hs:24:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, Filter (Equal Int) ()) Actual type: () In the expression: () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) In an equation for `test2': test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) ghc_bug2.hs:28:9: Couldn't match type `(Char, ())' with `()' Expected type: Filter (Equal Int) (Char, ()) Actual type: () In the expression: () In an equation for `test3': test3 = () }}} {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances, DataKinds #-} module Main where type family Filter f xs where Filter f (x, xs) = ApplyFilter (f x) (x, Filter f xs) Filter f () = () -- type family ApplyFilter p xs where ApplyFilter False (x, xs) = xs ApplyFilter p xs = xs -- type family Equal x y where Equal x x = True Equal x y = False -- -- Type checks test1 :: ApplyFilter ((Equal Int) Char) (Char, Filter (Equal Int) ()) test1 = () -- Couldn't match type `(Char, ())' with `()' test2 = () :: Filter (Equal Int) (Char, Filter (Equal Int) ()) -- Couldn't match type `(Char, ())' with `()' test3 :: Filter (Equal Int) (Char, ()) test3 = () -- Type checks, should not test4 :: Filter (Equal Int) (Char, ()) test4 = ('x', ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13379: Space leak / quadratic behavior when inlining
by GHC 27 Sep '17

27 Sep '17

#13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Compiling the attached example yields quadratic behavior and a big space leak (eventually the oom killer kills it) during inlining. Tested on both ghc 7.10.3 and 8.0.1 I compiled with `-fforce-recomp --make -O2 -ddump-inlinings Main.hs` In cases where the process was able to run for a while I could see that each chunk of inlinings was getting slower linearly (every minute or so you can hit enter and which the line break go up your terminal a little slower than the last time). I assume the slowdown is due to GC over the growing heap due to a leak, but maybe the inlining algorithm is quadratic. Apologies if this is a dupe; I had trouble searching for similar issues. (I did find #13316 but don't understand if this could be related) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2)
by GHC 27 Sep '17

27 Sep '17

#14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On Windows, the situation regarding Ctrl+C in GHCi has always been a little flaky in the sense that some shells (e.g., `mintty`-based ones) don't intercept Ctrl+C properly, causing GHCi to exit prematurely. However, up until 8.0.2, Ctrl+C was being intercepted correctly on `cmd.exe` and PowerShell. In GHC 8.2.1, however, this has changed. If you hit Ctrl+C in GHCi on PowerShell, then GHCi will appear to "exit" (in the sense that the prompt will go back to the PowerShell one). However, if you try typing and entering commands, there's a 50-50 chance it will be interpreted by PowerShell or a lingering GHCi process (indicating that GHCi wasn't really killed!). (Apologies for the rather crude description, but I'm not sure of a better way to report what is going on here.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13929: GHC panic with levity polymorphism
by GHC 27 Sep '17

27 Sep '17

#13929: GHC panic with levity polymorphism --------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I'm using GHC version 8.2.0.20170507 This code fails to compile {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Main where import GHC.Exts import Data.Kind import GHC.Generics class GUnbox (f :: Type -> Type) (r :: RuntimeRep) where type GUnboxed f r :: TYPE r gunbox :: f p -> GUnboxed f r instance (GUnbox f rf, GUnbox g rg) => GUnbox (f :*: g) ('TupleRep '[rf, rg]) where type GUnboxed (f :*: g) ('TupleRep '[rf, rg]) = (# GUnboxed f rf, GUnboxed g rg #) -- if I remove implementation of `gunbox` it compiles successfully gunbox (x :*: y) = (# gunbox x, gunbox y #) main :: IO () main = pure () }}} with message: {{{ [1 of 1] Compiling Main ( Main.hs, .stack- work\dist\f42fcbca\build\Main.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.2.0.20170507 for x86_64-unknown-mingw32): isUnliftedType GUnboxed g_a21y rg_a21z :: TYPE rg_a21z Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler\types\Type.hs:1954:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #12502: Reject wrong find utility
by GHC 27 Sep '17

27 Sep '17

#12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently our configure scripts try to find the correct find tool on the `PATH`. However because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first. The Configure script currently rejects the tool and continues trying to find the correct `find` utility from `msys2`. However the binary distribution script doesn't get to know which find utility to use. So if the wrong `find` is on the path then the windows binary downloads will fail with a weird error. The find utility to use should probably be passed to the tarballs download script. We could just stuff it in an `Env variable` and use it in the script if available. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13911: GHC RTS VEH swallowing exceptions
by GHC 26 Sep '17

26 Sep '17

#13911: GHC RTS VEH swallowing exceptions --------------------------------------+---------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- On ticket #6079, a top level VEH handler was implemented which effectively means there is no uncaught exceptions for those it catches. #13108 improved things a little by giving some basic info upon segfaults, but otherwise left everything as is. Rather than trying to catch all exceptions, I think it would be more worthwhile to leave them uncaught, and let current & future tools have an eyes open approach to debugging. If something needs to go in the place of the global handler, perhaps SetUnhandledExceptionFilter is of use? VEH overrides all other exception handlers as far as I'm aware (C++, SEH, .NET), so trying to interop with any other code that wants to handle it's own exceptions won't work unless said code is also using VEH. This is causing an issue for some code I've been working on, and I've documented similar to this bug report there also: https://gitlab.com/tim-m89/clr-haskell/issues/25#note_33960203 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5