- ghc-tickets - Haskell.org

Re: [GHC] #7889: Build Error (master branch)
by GHC 27 Aug '13

27 Aug '13

#7889: Build Error (master branch) -------------------------------------+--------------------------- Reporter: cg31 | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: gmp Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+--------------------------- Changes (by Rothiph): * cc: mikesteele81@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7889#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 27 Aug '13

27 Aug '13

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rrnewton): By the way, I've had various hard-to-pin-down problems with changing capabilities at runtime myself. Is it possible in this case to just disable the use of that feature for the initial release? That is, you would have to use +RTS -N to get real speedup. But, hey, it's kind of an advanced compilation feature anyway. In this scenario we could get a lot of testing experience with parallel builds without setNumCapabilities and then combine them when there is higher confidence. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3693: Show stack traces
by GHC 27 Aug '13

27 Aug '13

#3693: Show stack traces -------------------------------------+------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Tarrasch): Hello, I'm planning to take a serious look at this, it'll be my master thesis. I have a few questions here that I believe is of general interest. (1) Peter, your progress looks fantastic, and it's great to see that you can retrieve the stack trace both through a debugger ''and'' through the run-time system. But which one should we aim to use in the end? Opinions? I personally think having the run-time doing the job to be simpler for the users (If they are unfamiliar with debuggers) and more convenient (what if I forgot to run my program with `gdb`?) (2) By now, GHC have had the LLVM backend for a while. Would stack traces working for this backend be more useful? Would it be more/less work? LLVM has support for DWARF, but at this time I have a bad idea what that even means. But I do know some complications with the llvm approach. I've spoken with Nathan Howell about this and he thought that one missing piece is that the LLVM architecture only understands DWARF 3, but DWARF 4 is necessary to implement what we want. So we would need to patch LLVM. (3) Peter, would it be possible to show in somewhat more detail on how to reproduce the stack traces you pasted previously? It would be really useful if I could have some trail to follow when playing around. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3693#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 27 Aug '13

27 Aug '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------ Reporter: asr | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => thoughtpolice * priority: normal => highest * milestone: => 7.8.1 Comment: OK. `-fwarn-lazy-unlifted-bindings` is on by default ([http://www.haskell.org/ghc/docs/latest/html/users_guide/options- sanity.html documentation here]), with a message saying {{{ Foo.hs:6:11: Warning: Pattern bindings containing unlifted types should use an outermost bang pattern: }}} I propose: * To make `-fwarn-lazy-unlifted-bindings` into a no-op (that says "I do nothing"), and remove it altogether in 7.10. * To remove `-fwarn-lazy-unlifted-bindings` from the "on by default set" * To make lazy unlifted bindings an outright error. So GHC would reject {{{ f x = let I# y = x in ....blah.... }}} (Currently this elicits the warning, because y has type Int# in a lazy- looking binding.) * Fix the documentation to match. It would be possible (and easy to implement) to have a new language extension that allows such bindings, treating them as strict, which is what happens now. But given the long-standing warning and the easy fix, I'm disinclined to add this extra faff and documentation stuff. Any objections? Let's do this for 7.8. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8166: Undefined references in HEAD object files
by GHC 27 Aug '13

27 Aug '13

#8166: Undefined references in HEAD object files ----------------------------------+--------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- {{{ $ uname -a Linux default-centos-64.vagrantup.com 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux }}} When I try to bootstrap cabal-install using GHC HEAD: {{{ Checking installed packages for ghc-7.7.20130823... Cabal is already installed and the version is ok. transformers is already installed and the version is ok. mtl-2.1.2 will be downloaded and installed. deepseq is already installed and the version is ok. text-0.11.2.3 will be downloaded and installed. parsec-3.1.3 will be downloaded and installed. network-2.4.1.0 will be downloaded and installed. time is already installed and the version is ok. HTTP-4000.2.5 will be downloaded and installed. zlib-0.5.4.0 will be downloaded and installed. random-1.0.1.1 will be downloaded and installed. stm-2.4.2 will be downloaded and installed. Downloading mtl-2.1.2... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- 0 100 13723 100 13723 0 0 2432 0 0:00:05 0:00:05 --:--:-- 40964 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbw5_info': (.text+0x83f): undefined reference to `r9F5_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `sapv_info': (.text+0x1623): undefined reference to `r9F5_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbD6_info': (.text+0x17a9): undefined reference to `r9F5_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbHC_info': (.text+0x24ff): undefined reference to `r9F5_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `cbN4_info': (.text+0x3257): undefined reference to `r9F5_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o):(.text+0x3faf): more undefined references to `r9F5_info' follow /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ccEX_info': (.text+0xb63c): undefined reference to `r9F3_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt': (.data+0x38): undefined reference to `r9F5_closure' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Simple__63.o): In function `ScJo_srt': (.data+0x180): undefined reference to `r9F3_closure' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3WN_info': (.text+0x8a): undefined reference to `r3Eg_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5NF_info': (.text+0x118): undefined reference to `r3Eh_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3XR_info': (.text+0xc35): undefined reference to `r3Ei_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3YA_info': (.text+0xefe): undefined reference to `r3E8_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Z6_info': (.text+0x100e): undefined reference to `r3E8_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `s3Zb_info': (.text+0x1095): undefined reference to `r3Ei_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5X3_info': (.text+0x16d6): undefined reference to `r3E8_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `c5Xj_info': (.text+0x19d3): undefined reference to `r3E8_info' /usr/local/lib/ghc-7.7.20130823/Cabal-1.17.0/libHSCabal-1.17.0.a(Command__114.o): In function `S60p_srt': (.data+0x18): undefined reference to `r3E8_closure' (repeats ad nauseam) collect2: ld returned 1 exit status Error during cabal-install bootstrap: Compiling the Setup script failed }}} The full output can be found at https://gist.github.com/anonymous/e30cda2ca16f1e90e13e/raw/eb9b2d10db44d028… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8166> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 27 Aug '13

27 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by quchen): Thanks for the helpful hint, Simon. Just before I found that tcg_insts is a good place to look at by successively printing everything in the global environment, and you confirmed that that promising field is indeed correct. Now I can stop worrying about whether I'm coding everything based on a false premise :-) As some sort of status report, I think the core functionality of issuing the Applicative/Monad warnings is done now (and therefore also Alternative/MonadPlus). What's still missing is making this dependent on compiler flags, printing proper line numbers, and of course the "warn on custom join/<*>/pure" issue. (I should also credit danr for implementing the most significant parts up to this point.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 27 Aug '13

27 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): Ah, got it now, thanks. Indeed, there is a real issue here. `genPermutations` looks like this: {{{ genPermutations !n !l !r !perm !count = allocaArray n $ \ destF -> do let upd j !f run = do p0 <- peekElemOff perm 0 if p0 == 0 then increment perm count >> run f else do copyArray destF perm n increment perm count flopS destF $ \ flops -> run (f `mappend` F (checksum j flops) flops) let go j !f = if j >= r then return f else upd j f (go (j+1)) go l mempty where checksum i f = if i .&. 1 == 0 then f else -f }}} Now, just inline `checksum` and that call to `flopS` looks like {{{ flopS destF $ \ flops -> run (f `mappend` F (if then flops else -flops) flops) }}} Now `flopS` really does call its argument many times, so work really is saved by lifting out the constant expression to get: {{{ let lvl::Bool = j .&. 1 == 0 in flopS destF $ \ flops -> run (f `mappend` F (if lvl then flops else -flops) flops) }}} As it happens, in this case allocating the thunk may be more expensive than repeating the computation, but that's a bit hard for GHC to work out. Ideas welcome. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 27 Aug '13

27 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by rwbarton): Hi Simon, It's at lines 731-742 and then at lines 2242-2270 in the attachment; or you can find it by searching for `and#` (just one occurrence in each part of the dump) and taking a dozen or so lines around it. I hope I'm not misinterpreting the core, and `let { lvl6_s1Vb :: GHC.Types.Bool ... } in ...` is in fact a thunk allocation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7367: Optimiser / Linker Problem on amd64
by GHC 27 Aug '13

27 Aug '13

#7367: Optimiser / Linker Problem on amd64 --------------------------------------------+------------------------------ Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): rwbarton: thanks. It's really helpful to nail performance regressions. However I can't see the thunk you are referring to. Could you perhaps compile with `-ddump-simpl -ddump-stg` and point to the line number of the offending thunk allocation? (Perhaps also give the command line you are using to compile, so I can see what flags you are using.) Ta. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 27 Aug '13

27 Aug '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by simonpj): Do I gather that you are working in #8004? That's good. * Look in `tcg_insts` for instances defined in this module. * Look in `tcg_type_env` for Ids, TyCons, Classes, defined in this module. This type envt doesn't (I think) include imported things Both are fields of `TcGblEnv`. Does that help? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0