- ghc-tickets - Haskell.org

[GHC] #14648: ghc-pkg does handle unitids
by GHC 17 Jan '18

17 Jan '18

#14648: ghc-pkg does handle unitids -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.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: -------------------------------------+------------------------------------- I base the summary and the description on a single observation, see below. Sorry should this turn out to be a deduction too aggressive. == Assumed problem description New-style package-dbs can contain the same (package, version) entry multiple times, as entries are identified using an additional hash. I'll call the full identifier "unitId". The ghc-pkg interface seems to not support specifying full unitIds, i.e. "my-package-0.1.0.0-somehash" seems to be interpreted like "my-package-0.1.0.0-*". This is both a missing functionality and a bug: 1. many operations make sense per-unitId, not just per (package, version) 2. The fact that my-package-0.1.0.0-otherhash is unregistered by "ghc-pkg unregister my-package-0.1.0.0-somehash" is quite surprising. == Observation 1. Take a package-db containing the same (package, version) entry with two different hashes, e.g. - semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8 - semigroupoids-5.2.1-e50d44ead36c6b8428c9417007cee15bd9cbe3a2906c19553366d94b15c2471e I suggest making a copy of some existing (cabal store) db. 2. call `ghc-pkg --package-db my-copy unregister semigroupoids-5.2.1-2f552e489ce3109c2672606e2dc6e33c4f38174da930d5db0bb0dafbb4dccae8` 3. test `ghc-pkg --package-db my-copy list semigroupoids-5.2.1` Expected result: `semigroupoids-5.2.1-e50d44ea..` is still registered Observed result: empty list == Impact This blocks the use-case of a garbage-collection for the global new-style package db "store". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13683: Use epoll rather than poll where appropriate
by GHC 16 Jan '18

16 Jan '18

#13683: Use epoll rather than poll where appropriate ----------------------------------------+--------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Linux supports an `epoll` system call that's supposed to scale better to large numbers of watched file descriptors than `poll`. We should probably use it when available and appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13683> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14338: Simplifier fails with "Simplifier ticks exhausted"
by GHC 16 Jan '18

16 Jan '18

#14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While upgrading a codebase to GHC 8.2.1(it compiles reliably with 7.10.3) we encountered an issue with core simplifier(and rewrite rules if I correctly understood the meaning of RuleFired): {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying RuleFired Class op $p2HModify To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 10450410 1494659 PreInlineUnconditionally 149100 w_ipsJ 149095 w_ipps 149084 w_iplQ 149084 w1_iplR 149084 w2_iplS 149084 w3_iplT 149078 w_ipm7 149078 w1_ipm8 149078 w2_ipm9 149078 w3_ipma 120 $d~_iplr 120 $d~1_ipls 120 irred_iplu 120 eta_iplv 39 v_spsR 38 v_sp9c 38 v1_sp9d 38 v_spii 38 v1_spij 38 v2_spik 38 v3_spil 37 v_sp99 37 v1_sp9a 37 v_spin 37 v1_spio 37 v2_spip 37 v3_spiq 36 v_sp9f 36 v1_sp9g 36 v_spis ...skipping... 1 cobox1_apuk 1 cobox_apuq 1 cobox1_apur 1 cobox_apux 1 cobox1_apuy 2 CaseIdentity 2 ds1_iqAB 4 FillInCaseDefault 1 nt_sqyY 1 nt_sqz9 1 nt_sqze 1 nt_sqzj Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} We tried to shrink reproducible example to something reasonable and this is what we got: https://github.com/4e6/webapp-template-hs/tree/simpl-tick- factor Compiling it with stack build --ghc-options='-fsimpl-tick-factor=1000'(ten times the default) will demonstrate the issue. It fails reliably with a combination of servant and hset libraries. Removing one route from a servant API or moving the PayloadX to the head of type-level list makes it compilable again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #10972: Add a :binfo (beginner info) GHCi command
by GHC 16 Jan '18

16 Jan '18

#10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From goldfire: > Add a new command to GHCi, :binfo (for "beginner info") (please suggest a better name) that is like :info but presents different information. It suppresses in-scope instances, but attempts to specialize a function's type and presents specializations, using heuristics. So when we say :binfo find, we'll see Foldable t => (a -> Bool) -> t a -> Maybe a but also (a -> Bool) -> [a] -> Maybe a. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13647: Tidy up TcTypeable
by GHC 15 Jan '18

15 Jan '18

#13647: Tidy up TcTypeable -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- There is code in `TcTypeable` that generates a `KindRep` for each `TyCon` (see `Note [Representing TyCon kinds: KindRep]`). There's nothing actually wrong with it. But it's pretty hard to understand. And it generates a staggering amount of data structure, when compiling `GHC.Types`. {{{ Result size of Tidy Core = {terms: 74,615, types: 41,335, coercions: 2, joins: 0/0} }}} Why? Well, it injects a `TyCon` binding for each unboxed tuple size. For example, here is the code for pairs `(#,#)` {{{ $tc(#,#) = TyCon 16533601304077481746## 7902994497850328874## tr$ModuleGHCPrim $tc(#,#)2 2# $tc(#,#)1 -- TYPE #0 -> TYPE #1 -> TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $tc(#,#)1 :: KindRep $tc(#,#)1 = KindRepFun $krep2115_r6ji $krep18009_rarE $krep18009_rarE = KindRepFun $krep2117_r6jk $krep18008_rarD -- TYPE (TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)))) $krep18008_rarD = KindRepTyConApp $tcTYPE $krep18007_rarC $krep18007_rarC = : @ KindRep $krep18006_rarB ([] @ KindRep) -- TupleRep (': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep))) $krep18006_rarB = KindRepTyConApp $tc'TupleRep $krep18005_rarA $krep18005_rarA = : @ KindRep $krep2283_r6m0 ([] @ KindRep) -- ': RuntimeRep #0 (': RuntimeRep #1 ('[] RuntimeRep)) $krep2283_r6m0 = KindRepTyConApp $tc': $krep2282_r6lZ $krep2282_r6lZ = : @ KindRep $tc'AddrRep1 $krep2281_r6lY $krep2281_r6lY = : @ KindRep $krep61_r5Ma $krep2280_r6lX $krep2280_r6lX = : @ KindRep $krep2279_r6lW ([] @ KindRep) -- ': RuntimeRep #1 ('[] RuntimeRep) $krep2279_r6lW = KindRepTyConApp $tc': $krep2278_r6lV $krep2278_r6lV = : @ KindRep $tc'AddrRep1 $krep2277_r6lU $krep2277_r6lU = : @ KindRep $krep60_r5M9 $krep2276_r6lT $krep2276_r6lT = : @ KindRep $krep2274_r6lR ([] @ KindRep) -- '[] RuntimeRep $krep2274_r6lR = KindRepTyConApp $tc'[] $krep2273_r6lQ $krep2273_r6lQ = : @ KindRep $tc'AddrRep1 ([] @ KindRep) -- RuntimeRep $tc'AddrRep1 = KindRepTyConApp $tcRuntimeRep ([] @ KindRep) -------------- TYPE #0 $krep2115_r6ji = KindRepTyConApp $tcTYPE $krep2114_r6jh $krep2114_r6jh = : @ KindRep $krep61_r5Ma ([] @ KindRep) $krep61_r5Ma = KindRepVar 0# -------------- TYPE #1 $krep2117_r6jk = KindRepTyConApp $tcTYPE $krep2116_r6jj $krep2116_r6jj = : @ KindRep $krep60_r5M9 ([] @ KindRep) $krep60_r5M9 = KindRepVar 1# }}} That's a lot, and it's only for pairs. We generate all this up to 62-tuples! Suggestions (read `Note [Representing TyCon kinds: KindRep]` first) * `KindRep` is a description of a polykind; an interpreter, called `instantiateKindRep` turns it into a kind. So we can add whatever constructors we like to `KindRep`. * One good one would be `UnboxedTupleRep n`, which `instantiateKindRep` can instantiate to the kind of an unboxed tuple. It just moves the work somewhere else, of course, but it will make the generated code dramatically smaller. * We have a few canned kind-reps, via `TcTypeable.builtInKindReps`. It'd be simpler and easier instead to make each of them into a data constructor of `KindRep`. * Once that is done, I suspect that the entire machinery of tyring to share `KindReps` (which makes my head hurt) would be unnecessary None of this is essential, but I think that matters can be improved. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14663: Deriving Typeable for enumerations seems expensive
by GHC 15 Jan '18

15 Jan '18

#14663: Deriving Typeable for enumerations seems expensive -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 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 have a module `A10000` that looks like this: {{{ module A10000 where data A = A | A00001 | A00002 ... | A10000 }}} Currently compiling it with `./inplace/bin/ghc-stage2 A10000.hs +RTS -s` produces: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) 4,133,470,392 bytes allocated in the heap 1,194,866,080 bytes copied during GC 141,604,816 bytes maximum residency (14 sample(s)) 813,104 bytes maximum slop 341 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 329 colls, 0 par 0.551s 0.551s 0.0017s 0.0246s Gen 1 14 colls, 0 par 0.453s 0.453s 0.0323s 0.1031s 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.000s ( 0.000s elapsed) MUT time 1.498s ( 1.730s elapsed) GC time 1.004s ( 1.004s elapsed) EXIT time 0.000s ( 0.006s elapsed) Total time 2.502s ( 2.740s elapsed) Alloc rate 2,759,911,143 bytes per MUT second Productivity 59.9% of total user, 63.4% of total elapsed }}} I've noticed a lot of code getting generated (>500k lines of ASM), particularly interesting was code that supported `TyCon`s. I've tried again disabling the generation of `TyCon`s by modifying: {{{ mkTypeRepTodoBinds :: [TypeRepTodo] -> TcM TcGblEnv mkTypeRepTodoBinds _ = getGblEnv }}} This is the result: {{{ [1 of 1] Compiling A10000 ( A10000.hs, A10000.o ) 1,731,693,280 bytes allocated in the heap 280,362,376 bytes copied during GC 41,423,608 bytes maximum residency (10 sample(s)) 746,272 bytes maximum slop 102 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 401 colls, 0 par 0.111s 0.111s 0.0003s 0.0065s Gen 1 10 colls, 0 par 0.124s 0.124s 0.0124s 0.0298s 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.000s ( 0.000s elapsed) MUT time 0.773s ( 0.889s elapsed) GC time 0.235s ( 0.235s elapsed) EXIT time 0.000s ( 0.007s elapsed) Total time 1.008s ( 1.130s elapsed) Alloc rate 2,241,052,377 bytes per MUT second Productivity 76.7% of total user, 79.2% of total elapsed }}} It appears that by default I pay >50% of compile time for a feature that I probably won't use. I'm sorry if this is a duplicate, I've looked at https://ghc.haskell.org/trac/ghc/wiki/Typeable, but nothing seemed relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14663> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors
by GHC 15 Jan '18

15 Jan '18

#14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ghc-8.2.2 (probably since ghc-8.0.1), strict pattern matches in let bindings produce "Irrefutable pattern failed" errors. {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: <interactive>:2:5-13: Irrefutable pattern failed for pattern [] }}} In ghc-7.10.2, normal pattern match failures were produced. {{{#!hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: <interactive>:3:5-13: Non-exhaustive patterns in pattern binding }}} To my mind, the latter error makes much more sense; the effect of the ! is to make the pattern an ordinary, refutable one. Could the old behavior be restored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts
by GHC 15 Jan '18

15 Jan '18

#14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14456: Windows runtime linker failure with icuuc
by GHC 15 Jan '18

15 Jan '18

#14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): {{{ $ pacman -S mingw-w64-x86_64-icu }}} Now take this file: {{{#!hs module Main where import Data.Int import Foreign foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 main :: IO () main = c_ucnv_getMaxCharSize nullPtr >>= print }}} GHC is able to compile this successfully: {{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... }}} But GHCi is unable to accomplish the same thing: {{{ $ runghc -licuuc Bug2.hs ghc.exe: ^^ Could not load 'ucnv_getMaxCharSize_58', dependency unresolved. See top entry above. Bug2.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ucnv_getMaxCharSize_58 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 }}} Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7206: Implement cheap build
by GHC 15 Jan '18

15 Jan '18

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #8763 => #8763, #13422 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0