May 2017 - ghc-tickets

[GHC] #12912: IO library should not use select()
by GHC 27 Jun '17

27 Jun '17

#12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: | Version: 8.0.1 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: -------------------------------------+------------------------------------- The IO library uses `select()` in `fdReady()`, which fails in processes with more than 1024 file descriptors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13701: GHCi 2x slower without -keep-tmp-files
by GHC 26 Jun '17

26 Jun '17

#13701: GHCi 2x slower without -keep-tmp-files -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 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: -------------------------------------+------------------------------------- In D3562, I've observed that -keep-tmp-files makes :load 3x faster on my test case. I can't share my test case, but I've found a way to approximate it with `MultiLayerModules` I just added in D3575. Here are the steps: {{{ # in ghc top dir $ mkdir tmp $ cd tmp $ cp ../testsuite/tests/perf/compiler/genMultiLayerModules . # edit genMultiLayerModules to say DEPTH=0, WIDTH=5000 $ ./genMultiLayerModules $ echo ':load MultiLayerModules' | ../inplace/bin/ghc-stage2 --interactive +RTS -s 11,132,224,952 bytes allocated in the heap 1,004,238,408 bytes copied during GC 185,091,216 bytes maximum residency (14 sample(s)) 2,813,504 bytes maximum slop 365 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 706 colls, 0 par 0.907s 0.906s 0.0013s 0.0125s Gen 1 14 colls, 0 par 0.607s 0.606s 0.0433s 0.2244s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.000s elapsed) MUT time 20.219s ( 20.493s elapsed) GC time 1.514s ( 1.513s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 21.733s ( 22.010s elapsed) Alloc rate 550,585,275 bytes per MUT second Productivity 93.0% of total user, 93.1% of total elapsed $ echo ':load MultiLayerModules' | ../inplace/bin/ghc-stage2 --interactive -keep-tmp-files +RTS -s 4,603,831,672 bytes allocated in the heap 971,623,904 bytes copied during GC 184,019,808 bytes maximum residency (14 sample(s)) 2,262,680 bytes maximum slop 365 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 448 colls, 0 par 0.724s 0.723s 0.0016s 0.0321s Gen 1 14 colls, 0 par 0.621s 0.620s 0.0443s 0.2242s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.000s elapsed) MUT time 7.966s ( 8.202s elapsed) GC time 1.345s ( 1.344s elapsed) EXIT time 0.000s ( 0.004s elapsed) Total time 9.312s ( 9.550s elapsed) Alloc rate 577,938,762 bytes per MUT second Productivity 85.5% of total user, 85.9% of total elapsed }}} So it's 2x slower and allocates 2.5x more. Profiling pointed to https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/S… We're creating `dont_delete_set` a lot. Looks like this was improved in D3111 recently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12412: SIMD things introduce a metric ton of known key things
by GHC 26 Jun '17

26 Jun '17

#12412: SIMD things introduce a metric ton of known key things -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- In #12357 we were looking at reducing the number of entries in the `knownKeyNames`. This has the potential to improve compiler performance since this set of things is always present in the original name cache, which is often referred to. #12357 reduced the number of elements in `knownKeyNames` from 2017 to 1834. Not a bad improvement. That being said, the SIMD operations introduce nearly four times that number. These include things like `readWord64OffAddrAsWord64X2#`, `indexInt16OffAddrAsInt16X16#`, and `remInt16X16#`. All in all these operations constitute nearly a third of the known key names. I'm not really sure what can be done about this, but I thought it should be noted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector
by GHC 26 Jun '17

26 Jun '17

#10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling attached source file, GHC panics. The following is the error message. {{{ $ ghc -Wall Vec3.hs [1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Size.intSize W256 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Currently native code generator does not support SIMD operations, and my computer does not support AVX instructions. Therefore ghc cannot compile the source at any case. So I think this bug is not so important. My system environment. {{{ $ uname -a Linux think 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions
by GHC 24 Jun '17

24 Jun '17

#13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8668 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a boiled down version of a library I'm working on. It's possible this is the same issue as #8668 which seems to have stalled. Hopefully this example is simpler and useful in that case. Also likely the same as this https://github.com/jmoy/testing-specialize I have a library which defines the classes `H` and `S`; library consumers are likely to define their own `H` instances, and import `S` instances declared by ''other'' library authors (not me), who will depend on my `H`. Performance depends on all of it getting fully-specialized `hash` (i.e. for each combination of `H` and `S` that the consumer uses). But I don't really want `hash` inlined at every call site. Here is the code to repro with explanation below. I'm compiling like: `ghc --make -Wall -O2 -rtsopts -funbox-strict-fields -ddump-to-file -ddump- simpl -dsuppress-module-prefixes -dsuppress-uniques -ddump-core-stats -ddump-inlinings -ddump-asm -fforce-recomp Main.hs`, and we get the same bad behavior on GHC 7.10.3 and GHC 8.0.1: Lib.hs: {{{#!hs module Lib where class H h where hash :: (S s)=> s -> h -> s class S s where mix :: s -> Int -> s instance H Int where {-# INLINABLE hash #-} hash s = \x -> s `mix` x -- make this look big: `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x }}} S.hs: {{{#!hs module S where import Lib newtype Foo = Foo Int deriving Show instance S Foo where {-# INLINABLE mix #-} mix (Foo x) y = Foo (x+y) }}} And the `Main` I'm using, though you can just call print; it's obvious dumping inlinings when the functions get specialized and unboxed (look for "Inlining done: $fNumInt_$c+"): {{{#!hs module Main where import Lib import S import Criterion.Main main = defaultMain [ bench "foo" $ whnf (hash (Foo 1)) (1::Int) ] }}} If I use the `INLINABLE` pragmas above or omit them entirely we get bad code. If I put an `INLINE` on the `hash` declaration in Lib (and no pragmas in S), we get good unboxed additions and things are fast. Finally and most bizarrely, if I omit the `INLINE` pragma in `hash` (and similarly no pragmas in `S`) but make the body small enough (5 lines of the "`mix` x `mix` x..." junk) then we also get nice unboxed code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications
by GHC 23 Jun '17

23 Jun '17

#12978: User guide section on AllowAmbiguousTypes should mention TypeApplications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… #ghc-flag--XAllowAmbiguousTypes With type applications it is tempting to write {{{ class C x a where meth :: a }}} which will fail the ambiguity check as `x` is not used in any methods. One way to get around this is to use `TypeApplications` in order to specify what `x` should be at each usage of `meth`. A small section in the user guide explaining this and linking to the section on `TypeApplications` would be useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining.
by GHC 23 Jun '17

23 Jun '17

#11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language PatternSynonyms , ViewPatterns #-} import Text.Read -- pattern PRead :: () => Read a => a -> String pattern PRead a <- (readMaybe -> Just a) foo :: String -> Int foo (PRead x) = (x::Int) foo (PRead xs) = sum (xs::[Int]) foo _ = 666 bar :: String -> Int bar (readMaybe -> Just x) = (x::Int) bar (readMaybe -> Just xs) = sum (xs::[Int]) bar _ = 666 main :: IO () main = do print $ foo "1" -- 1 print $ foo "[1,2,3]" -- 666 -- ??? print $ foo "xxx" -- 666 print $ bar "1" -- 1 print $ bar "[1,2,3]" -- 6 print $ bar "xxx" -- 666 }}} I'm expecting that semantics of the function `foo` would not change if I inline pattern synonym. However it does. `bar` successfully matches string against list of ints, whereas `foo` apperently skips this pattern and fall back to the catch-all case. Reproducible both in GHCi and GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #13009: Hierarchical Module Structure for GHC
by GHC 23 Jun '17

23 Jun '17

#13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | 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: | ModuleDependencies/Hierarchical -------------------------------------+------------------------------------- Currently GHC's modules are not hierarchical and have very short cryptic names. I would like to revive this 8-year old proposal: https://ghc.haskell.org/trac/ghc/wiki/ModuleDependencies/Hierarchical Pros: * cleaner code base and overall code structure easier to grasp * better integration with other packages when using GHC API * better documentation (cf https://www.stackage.org/lts-7.14/package/ghc-8.0.1) Cons: * break the GHC (plugin) API * may make "rebase" harder during the transition period -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12379: WARN pragma gives warning `warning: [-Wdeprecations]'
by GHC 22 Jun '17

22 Jun '17

#12379: WARN pragma gives warning `warning: [-Wdeprecations]' -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example: {{{#!hs -- Warn.hs module Warn where __todo :: String -> a {-# WARNING __todo "TODO" #-} __todo msg = error $ "TODO: " ++ msg }}} {{{#!hs -- Main.hs {- OPTIONS_GHC -Wall #-} import Warn inc :: Int -> Int inc n | n >= 0 = n + 1 inc _ = __todo "what about negatives?" }}} When compile the files (or ghci), I get {{{ UseWarn.hs:9:9: warning: [-Wdeprecations] In the use of ‘__todo’ (imported from Warn): "TODO" }}} Should the flag be `-Wwarnings-deprecations`? And `-Wdeprecations` is not in the user guide, if it is a genuine flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12379> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13295: Failure to resolve type parameter determined by type family
by GHC 22 Jun '17

22 Jun '17

#13295: Failure to resolve type parameter determined by type family -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Proxy -- Defined to get the type forall x . 'D x data D where D :: a -> D type family F t :: D -- Will try to create values of this type through the type family -- F, i.e. G (F t) data G (d :: D) where G :: G ('D x) -- This is rejected because the type variable x in 'D x is ambiguous. -- But is it really? If there's an instance of F t then x is determined. introG :: Proxy t -> G (F t) introG _ = G -- introG is well-typed if we add an equality constraint. -- Can GHC not figure this out without our help? introG' :: forall t x . ( F t ~ 'D x ) => Proxy t -> G (F t) introG' _ = G }}} Here's the type error: {{{ • Couldn't match type ‘F t’ with ‘'D x0’ Expected type: G (F t) Actual type: G ('D x0) The type variable ‘x0’ is ambiguous • In the expression: G In an equation for ‘introG’: introG _ = G }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4