August 2015 - ghc-tickets

[GHC] #8793: Improve GHC.Event.IntTable performance
by GHC 09 Jan '16

09 Jan '16

#8793: Improve GHC.Event.IntTable performance ------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The performance of `GHC.Event.IntTable` can be improved. I've managed to get some nice increases across the board. Benchmarking using `criterion` shows: function, % faster than current impl. `insert`: 4% `lookup`: 26% `update`: 11% `delete`: 5% There is one strange thing I noted. In `updateWith`, there is an inner loop that looks like this: {{{ data Bucket a = Empty | Bucket Int a (Bucket a) go _ Empty = (False, Nothing, Empty) go cont (Bucket key val next) | key == k = case f val of Nothing -> (True, Just val, cont next) Just v -> (False, Just val, cont (Bucket key v next)) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which returns a tuple that is immediately consumed like so: {{{ (delete_occurred, old_val, new_bkt) <- go id ... when (isJust old_val) $ do <updateIntTable> when delete_occurred <decIntTableSize> return old_val }}} I expected that inlining the `<updateIntTable>` and `<decIntTableSize>` code blocks directly into `go` would result in better code than creating a tuple and then pattern matching on it afterwards. ie. {{{ go _ Empty = return Nothing go cont (Bucket key val next) | key == k = do case f val of Nothing -> <updateIntTable> (cont next) >> <decIntTableSize> Just v -> <updateIntTable> (cont (Bucket key v next) return (Just val) | otherwise = go (\x -> cont (Bucket key val x)) next }}} which has the exact same semantics. To my suprise, this code is almost 2x slower! The core generated in both cases is exactly what I'd expect; if anything, the second version seems tighter. I'm not sure why the first version is faster, but perhaps the original author, Bryan O'Sullivan, can shed some light as he used the tupled method in the first version. I'll attach my patch, `criterion`'s html output for the benchmarks as well as the benchmarking code, and the core for the oddity I discussed above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10337: One-shot module loops have hard to understand messages
by GHC 09 Jan '16

09 Jan '16

#10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider these two modules: {{{ -- A.hs module A where -- B.hs module B where import A }}} `ghc --make B.hs` will compile this fine. Now edit `A.hs` to be circular: {{{ -- A.hs module A where import B }}} and attempt to one-shot compile it with `ghc -c A.hs`. You will now get an uninformative error message: {{{ A.hs:1:1: Circular imports: module `A' depends on itself }}} You can get a more informative message with `--make`: {{{ Module imports form a cycle: module `A' (A.hs) imports `B' (./B.hs) which imports `A' (A.hs) }}} We should either suggest users try again with `--make`, or try harder to give a useful message in one-shot mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10362: Make tuple constraints into a class
by GHC 09 Jan '16

09 Jan '16

#10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment GHC treats tuple constraints specially. If you grep for `TuplePred` you'll see this. But the special treatment is strange; see the confusion between constraint tuples and ordinary tuples in #9858. But I now realise that we can sweep away all this nonsense. Suppose we declare {{{ module GHC.Classes where class (c1, c2) => (,) c1 c2 instance (c1, c2) => (,) c1 c2 class (c1, c2, c3) => (,) c1 c2 c3 instance (c1, c2, c3) => (,) c1 c2 c3 }}} and so on. (This is analogous the tuple data type declarations in `GHC.Tuple`.) Notice that: * `GHC.Classes,(,)` is a class, of kind `Constraint -> Constraint -> Constraint`. quite distinct from `GHC.Tuple.(,)`, whose kind is `* -> * -> *`. * `GHC.Classes.(,)` is a perfectly ordinary class, with no methods and two superclasses. * So all the usual superclass stuff applies. * If you have a given `Ord a` then you have a given `Eq a` (its superclass). Similarly if you have a given `(,) c1 c2` then you also have given `c1` and `given `c2`. * If you want to construct a dictionary of type `Ord a` (a "wanted"), you must supply a dictionary of type `Eq a`. Similarly, if you want to construct a dictionary of type `(,) c1 c2` then you must supply `c1` and `c2`. * I have written `(,) c1 c2` to stress that there is a class `GHC.Classes.(,)`, but we'll also allow the concrete syntax `(c1,c2)` instead. * Nevertheless the syntactic form `(c1, c2) => blah` is just sugar for `c1 => c2 => blah` (a type with two, curried constraints); it does not stand a type with a single constraint. Otherwise the instance {{{ instance (c1,c2) => (c1,c2) }}} would be the identity function! The key thing is that, aside from special syntax, `(,)` is a perfectly ordinary class, so we can simply delete all the special treatment of `TuplePred`. (Implicit parameters are also treated as a special class, incidentally.) There should be no user-visible effects. But I think it would cure the worst aspects of #10359, as well as cleaning up `TypeRep` confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9009: Confusing error message when loading package with TH
by GHC 08 Jan '16

08 Jan '16

#9009: Confusing error message when loading package with TH ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I got this error message when compiling a file that calls Template Haskell function from `singletons` package: {{{ [1 of 1] Compiling Splices ( Splices.hs, Splices.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package th-desugar-1.4.0 ... linking ... done. Loading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info) }}} After some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules
by GHC 08 Jan '16

08 Jan '16

#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -----------------------------------+--------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely. The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal- dev, the following error is generated: {{{ cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure Resolving dependencies... Configuring second-0.1... cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build Building second-0.1... Preprocessing library second-0.1... [1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package network-2.4.1.2 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package hslogger-1.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package first-0.2 ... linking ... ghc: /home/some- directories/example/first/../cabal-dev- sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure' ghc: unable to load package `first-0.2' make[1]: *** [build] Error 1 }}} Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed: {{{ $ objdump -t cabal-dev- sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info }}} (While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.) If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects). Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9969: panic in T7562
by GHC 07 Jan '16

07 Jan '16

#9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: T7562 | Blocked By: Blocking: | Related Tickets: #7562 Differential Revisions: | -------------------------------------+------------------------------------- Various people observe this test failure: {{{ =====> T7562(normal) 869 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history -c T7562.hs -fno-warn-incomplete-patterns >T7562.comp.stderr 2>&1 Compile failed (status 256) errors were: T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of ‘Pair2’ In the definition of data constructor ‘Pair2’ In the data declaration for ‘Pair2’ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150108 for x86_64-unknown-linux): toIfaceBang Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to my logs, this was caused by changeset:9564bb8c84cbc0397a414e946cc8c28801f0fbe7/ghc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9960: Performance problem with TrieMap
by GHC 07 Jan '16

07 Jan '16

#9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Looking at #9805 reminded me. When investigating the performance of #9872 I found a major performance hole in `TrieMap`. Suppose we have a handful H of entries in a `TrieMap`, each with a very large key, size K. If you fold over such a `TrieMap` you'd expect time O(H). That would certainly be true of an association list! But with `TrieMap` we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). This is pretty bad. In test `T9872` I found that 90% of compile time was spent in `TrieMap` as we repeatedly built, folded, and then rebuilt `TrieMap`s. I fixed that by keeping smaller `TrieMap`s, but the underlying problem remains. The point of a `TrieMap` is that you need to navigate to the point where only one key remains, and then things should be fast. So I think that `TypeMap`, say, should look like {{{ data TypeMap a = EmptyTM | SingletonTM Type a | TM { tm_var :: VarMap a , tm_app :: TypeMap (TypeMap a) , tm_fun :: TypeMap (TypeMap a) , tm_tc_app :: NameEnv (ListMap TypeMap a) , tm_forall :: TypeMap (BndrMap a) , tm_tylit :: TyLitMap a } }}} The `SingletonTM` means that, once you are down to a single (key,value) pair, you stop and just use `SingletonTM`. Tiresomely, because of the deBruijn thing, it'd need to be {{{ ... | SingletonTM (CMEnv, Type) a ... }}} and we'd need an auxiliary function for equality: {{{ eqTypeModuloDeBruijn :: (CMEnv, Type) -> (CEnv, Type) -> Bool }}} But that's not hard. Very similar to the way `RnEnv2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10744: Allow oneShot to work with unboxed types
by GHC 07 Jan '16

07 Jan '16

#10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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: Differential Revisions: | -------------------------------------+------------------------------------- Currently `oneShot` requires that both the argument type and the return type of the given function have the kind `*`. It would be nice if I could use unlifted types there. The following program demonstrates this: {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Exts import GHC.Magic f0 :: Int -> Int f0 = oneShot $ \n -> n -- OK f1 :: Int# -> Int f1 = oneShot $ \n# -> I# n# -- Error, the argument type is unlifted f2 :: Int -> Int# f2 = oneShot $ \(I# n#) -> n# -- Error, the result type is unlifted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults
by GHC 07 Jan '16

07 Jan '16

#8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8652: Cross-compiling broken for ARM/Linux target
by GHC 07 Jan '16

07 Jan '16

#8652: Cross-compiling broken for ARM/Linux target ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- I've attempted to cross compile GHC HEAD on Ubuntu 13.10 with ubuntu's hard-float tool-chain and LLVM. I've configured GHC with: {{{ $ ./configure --target=arm-linux-gnueabihf }}} and compiling by make works till it fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabihf-nm" /usr/bin/arm-linux-gnueabihf-nm: includes/dist- derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabihf-nm "includes /dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 }}} As a workaround for this issue, it's possible to use --with-gcc= and this way deriveConstants gets the right cross GCC. Looks like a bug somewhere in make machinery or configure itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3