January 2014 - ghc-tickets

Re: [GHC] #6135: Unboxed Booleans
by GHC 18 Jan '14

18 Jan '14

#6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by carter): @lemming, Bool# is now Int# afaik, could you explain what you mean? even if we used a i1 rep, it still needs a full register! So theres no lost for the in register rep to be Int#, afaik -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:90> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 18 Jan '14

18 Jan '14

#6135: Unboxed Booleans ---------------------------------------------+----------------------------- Reporter: benl | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: primops/should_run/T6135 | Difficulty: Unknown Blocking: | Blocked By: 8103, | 8103 | Related Tickets: #605 ---------------------------------------------+----------------------------- Comment (by Lemming): Btw. LLVM usually represents boolean values by type `i1`. It would certainly be easier to translate `Bool#` to `i1`, than translating `Int#` to `i1` in a special case. But as I understand the `Bool#` type was finally rejected in order to optimize all enumeration types the same way, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:89> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7775: Mark intentionally omitted type class instances
by GHC 18 Jan '14

18 Jan '14

#7775: Mark intentionally omitted type class instances --------------------------------------------+------------------------------ Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Resolution: wontfix | Keywords: instance Operating System: Unknown/Multiple | warning Type of failure: None/Unknown | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by Lemming): * version: 7.6.2 => 7.7 Comment: There is still a difference between intentionally and unintentionally omitted instances. I find it important to document for me and for others why I have omitted an instance. Also without the "possible fix" message people keep asking why an obvious instance is missing. "Why is this parser not Monoid?" - maybe because there are different ways of viewing it as Monoid. "Why is this identifier type not Num?" - maybe because it makes no sense to multiply identifiers. Or even worse, people do not just ask but start writing (conflicting) orphan instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7775#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8679: Extend FunD data constructor with information about type signature
by GHC 18 Jan '14

18 Jan '14

#8679: Extend FunD data constructor with information about type signature ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I want to propose that `FunD` data constructor in Template Haskell is extended with a field that contains that function's type signature (if present). Currently the type signature is a separate declaration represented with `SigD`. I motivate my proposal with the fact that function and its type signature are not independent and it might be the case that processing one requires knowledge of the other. Here's a concrete example. Recently I've been working together with Richard Eisenberg on promoting higher-order functions to the type level. To promote a higher order function I need to replace applications of a function passed as a parameter with usage of a special `Apply` type family. For example the definition of `map`: {{{ map :: (a -> b) -> [a] -> [b] map _ [] = [] map f (x:xs) = f x : map f xs }}} will be promoted to: {{{ type family Map (f :: (TyFun k1 k2) -> *) (list :: [k1]) :: [k2] where Map f '[] = '[] Map f (x ': xs) = Apply f x ': Map f xs }}} To generate equations in the `Map` type family from declarations stored by a `FunD` data constructor I need to know that `f` is a function. The only way for me to know this is by promoting type signature stored in `SigD` and checking the type of `f`. But to promote type signature to a type family I need to know the number of patterns in a function clause, which again is stored in `FunD`. In other words my algorithm looks like this: 1. Recover number of patterns in a function clause 2. Based on number of paterns in function's clause promote the type signature to a type family 3. Based on promoted type signature and definitions in `FunD` generate equations in the type family. Since `FunD` and `SigD` are independent I need to do three separate passes (or two passes + some hacking). If `FunD` contained informatuon about type signature I could achieve the same in one pass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8679> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8564: Unhandled ELF relocation types on dynamically loading object files with GHCi
by GHC 18 Jan '14

18 Jan '14

#8564: Unhandled ELF relocation types on dynamically loading object files with GHCi ------------------------------------+------------------------------- Reporter: pgj | Owner: pgj Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- GHCi cannot handle ELF symbols with relocation types 15 (i386) and 22 (amd64) (such as {{{ThreadRuneLocale}}}, coming from libc on systems later than 9.0) when dynamically loading object files. This can be reproduced by the issuing the following commands: {{{ # pkg install hs-hs-bibutils .. $ ghci Prelude> :m Text.Bibutils Prelude> bibl_init Loading package syb-0.4.0 ... linking ... done. Loading package hs-bibutils-5.0 ... linking ... <interactive>: /usr/local/lib/cabal/ghc-7.6.3/hs-bibutils-5.0/HShs-bibutils-5.0.o: unhandled ELF relocation(Rel) type 15 ghc: unable to load package `hs-bibutils-5.0' Prelude> }}} The source file {{{rts/Linker.c}}}, function {{{do_Elf_Rela_relocations()}}} is missing the case branches for types 15 ({{{R_386_TLS_IE}}}) and 22 ({{{R_X86_64_GOTTPOFF}}}). They shall be implemented for FreeBSD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8564> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8451: Link problem on FreeBSD
by GHC 18 Jan '14

18 Jan '14

#8451: Link problem on FreeBSD ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: high | Version: 7.7 Component: Compiler | Operating System: FreeBSD Keywords: | Type of failure: GHC doesn't work at all Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- GHC head on FreeBSD causes a link error if -prof and -threaded are specified: {{{ % cat main.hs main = putStrLn "hello" % ghc -prof -threaded main.hs [1 of 1] Compiling Main ( main.hs, main.o ) /usr/local/lib/gcc47/gcc/x86_64-portbld- freebsd9.1/4.7.3/../../../../../x86_64-portbld-freebsd9.1/bin/ld: cannot find -lthr collect2: error: ld returned 1 exit status }}} Note that libHSrts_thr* are certainly installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 17 Jan '14

17 Jan '14

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: nomeata Type: task | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Moderate (less performance bug | than a day) Test Case: | Blocked By: Blocking: | Related Tickets: #8598 -------------------------------------+------------------------------------- Comment (by nomeata): Small status update: My work on nested CPR has now reached somewhat conclusive state. The performance changes are not great, but it is still nice to have, especially if users who would re-write their code for performance would no longer have to do so. It should not go in for 7.8 – the gains are too small, and there still might be corner cases bugs. So I plan to merge it somewhen after 7.8. Until then, the branch `wip/nested-cpr` contains the changes in mostly cleaned-up, individually validated patches. I might occasionally rebase that branch to keep the conflicts small. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7619: Make worker-wrapper unbox data families
by GHC 17 Jan '14

17 Jan '14

#7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): The package inst-env get extended by a kind of side effect when we lad new modules. The home-package inst env doesn't. You could combine them into one and pass one instead of a pair, but not much would be gained, and there'd be some extra computation to build the combined env that might only be interrogated once. Nothing deep -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7619#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7619: Make worker-wrapper unbox data families
by GHC 17 Jan '14

17 Jan '14

#7619: Make worker-wrapper unbox data families -------------------------------------+------------------------------------ Reporter: akio | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: type family Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): This is actually simple to implement (see [a1ddb71/ghc] on branch `wip/T7619`), but rather ugly due to the additional passing of the FamInstEnv everywhere. That’s why I did not push to master yet. There are types `FamInstEnvs` and `FamInstEnv`, but it is not well- explained, only {{{ type FamInstEnvs = (FamInstEnv, FamInstEnv) -- External package inst-env, Home-package inst-env }}} Note that `topNormaliseType_maybe` takes a `FamInstEnvs`, and I can get a `FamInstEnv` from the `ModGuts` and from `ExternalPackageState`. If I combine these as follows, am I doing the right thing? {{{ doPassDFU :: (DynFlags -> FamInstEnvs -> UniqSupply -> CoreProgram -> CoreProgram) -> ModGuts -> CoreM ModGuts doPassDFU do_pass guts = do dflags <- getDynFlags us <- getUniqueSupplyM hsc_env <- getHscEnv eps <- liftIO $ hscEPS hsc_env let fam_envs = (eps_fam_inst_env eps, mg_fam_inst_env guts) doPass (do_pass dflags fam_envs us) guts }}} And why do we need to make that distinction in the first place – it seems that `topNormaliseType_maybe` does not treat them differently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7619#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8675: make sdist fails in HEAD
by GHC 17 Jan '14

17 Jan '14

#8675: make sdist fails in HEAD ------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- make sdist failed on my Linux box with this message: {{{ mv sdistprep/ghc/ghc-7.7.20140117/utils/genprimopcode///Parser.y sdistprep/ghc/ghc-7.7.20140117/utils/genprimopcode///Parser.y.source "cp" utils/haddock/dist/build/Haddock/Lex.hs sdistprep/ghc/ghc-7.7.20140117/utils/haddock/src/Haddock cp: cannot stat ‘utils/haddock/dist/build/Haddock/Lex.hs’: No such file or directory make[1]: *** [sdist-ghc-prep] Error 1 make: *** [sdist] Error 2 }}} My last successful make sdist was on January 12th. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8675> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2