April 2017 - ghc-tickets

[GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout
by GHC 30 Sep '17

30 Sep '17

#10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{RTS -qa}}} option that can set thread affinity was implemented in https://git.haskell.org/ghc.git/commitdiff/31caec794c3978d55d79f715f21fb729… {{{ // Schedules the thread to run on CPU n of m. m may be less than the // number of physical CPUs, in which case, the thread will be allowed // to run on CPU n, n+m, n+2m etc. void setThreadAffinity (nat n, nat m) }}} Today I discovered that on some machines, this option helps parallel performance (e.g. {{{+RTS -N4}}}) a lot, while on others it doesn't. Together with thomie on #ghc, I found out the reason: Lets assume I have 4 real cores with hyperthreading, so 8 virtual cores. The mapping of hyperthreading cores to physical cores is different across machines. On my one machine (Intel i5), the layout is 11223344, meaning that the first two vCPUs (hyperthreads) that the OS announces (visible e.g. in HTOP) map to the first physical core in the system, and so on. On my other machine (Intel Xeon), the layout is 12341234; here the 1st and the 5th vCPU map to the same physical core. This layout can be (on Linux) observed by running: {{{ cat /proc/cpuinfo|egrep "processor|physical id|core id" |sed 's/^processor/\nprocessor/g' }}} I do not know whether this layout is dictated by the processor, chosen by the OS, or even changing across reboots; what is clear is that the layout can vary across machines. Now, as explained by thomie: {{{ -qa will set your 4 capabilities to cores [(1,5), (2,6), (3,7), (4,8)], and then the os randomly chooses out of those tuples }}} This strategy is optimal for the 12341234 layout; for example, when running with -N4, it ensures that two threads are not scheduled onto vCPUs that are on the same physical core. The possible {{{+RTS -aq}}} choice {{{1__4_23_}}} is a great assignment in this case, as is {{{1234____}}} ({{{_}}} means the vCPU is not chosen). But for the 11223344, the choice {{{1234____}}} isn't good, because it uses only 2 of our 4 physical cores; our program now takes twice as long to run. ---- It seems likely to me that {{{setThreadAffinity}}} was written on a machine with 12341234 layout, and with the assumption that all machines have this layout. It would be great if we could change it to take the actual layout into account. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10941: Large heap address space breaks valgrind
by GHC 29 Sep '17

29 Sep '17

#10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | -------------------------------------+------------------------------------- It seems that programs compiled with a GHC `--enable-large-address-space` (see #9706) no longer run under valgrind, which is a pitty, as that is useful to get more reliable numbers out of nofib. It fails with `internal error: getMBlock: mmap: Invalid argument` This bug is a general “Can we do anything about this”. In particular, is there a possibility to make this a RTS option instead of a compile time option? Or maybe it is possible to talk to the valgrind authors if they can support such large allocations? If neither, can we maybe extend the error message to say “If you are using a tool like valgrind, you might want to recompile the compiler with `--disable-large-address-space.” -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved.
by GHC 29 Sep '17

29 Sep '17

#11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, orf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11228> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13391: PolyKinds is more permissive in GHC 8
by GHC 28 Sep '17

28 Sep '17

#13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docs claim that the definition in section 9.11.10 {{{ data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} "requires that `-XTypeInType` be in effect", but this isn't the case. The following compiles with GHC-8.0.2: {{{ {-# LANGUAGE PolyKinds, GADTs #-} data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} The example does *not* compile with 7.10.3, so this seems to be a case where `-XPolyKinds` has become more permissive in GHC 8 (as outlined in section 9.11.1). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #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] #12502: Reject wrong find utility
by GHC 26 Sep '17

26 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