- ghc-tickets - Haskell.org

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): David says: Hey everyone, I'm having trouble finding a good middle ground between the global and local environments in the typechecker. I would like to get an environment of things that are defined in the current module, but * `TcGblEnv` includes everything in scope, which is too general. * `TcLclEnv` is (if I'm right) meant to handle scoping, which is too narrow. The reason for this is that the AMP warnings should be restricted to a single module. In the current implementation, having a module import an AMP-violating module issues a warning from each module using the offender (including that module itself). It does the job, but it's not pretty. David -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:6> 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 simonmar): The changes to handle loops look OK to me, but I would test it on a GHC build to be sure. You want to build the whole of `ghc/compiler` with `--make -O2`; the build system doesn't do this so you have to make a command line by hand. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 27 Aug '13

27 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.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 simonpj): Looks good. Needs user documentation though! Thanks. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1687: A faster (^)-function.
by GHC 27 Aug '13

27 Aug '13

#1687: A faster (^)-function. ---------------------------------+--------------------------- Reporter: moonlite@… | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by simonpj): moonlite, rwbarton: just to say, thank you for working on this. If you need help on GHC aspects just ask, but meanwhile, I'll hope that you'll develop a patch! Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1687#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1687: A faster (^)-function.
by GHC 27 Aug '13

27 Aug '13

#1687: A faster (^)-function. ---------------------------------+--------------------------- Reporter: moonlite@… | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by rwbarton): * cc: rwbarton@… (added) Comment: moonlite's algorithm does squaring and multiplication by the small number `x`, while GHC's algorithm does squaring and multiplication of those squares together in an accumulator. Squaring big integers is a constant factor faster than multiplying different numbers of similar size, so moonlite's algorithm wins on Integer when the numbers involved are large. The downside is that it is not tail-recursive, which costs when multiplications are actually very cheap like for Int. But anyways, how about binding to `mpz_pow_ui` and using a RULE in the case of Integer base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1687#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7980: runghc dies silently when given large numbers of arguments. Compiled code does not.
by GHC 27 Aug '13

27 Aug '13

#7980: runghc dies silently when given large numbers of arguments. Compiled code does not. ------------------------------------------------+-------------------------- Reporter: totherme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * cc: rwbarton@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7980#comment:3> 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): Based on an examination of the Core, GHC HEAD (and presumably 7.6 though I don't have it to test) is floating the expression `i .&. 1 == 0` out of `\f -> ...` in `checksum`, resulting in the allocation of a thunk per execution of the `go`/`upd` loop in `genPermutations`. GHC 7.4 doesn't perform this "optimization" in this particular program. Not sure why. The allocations under GHC HEAD can be eliminated with a change to the benchmark program like this: {{{ --- f-orig.hs 2013-08-26 19:42:27.000000000 -0400 +++ f.hs 2013-08-26 19:30:09.000000000 -0400 @@ -64,11 +64,11 @@ 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) + if j .&. 1 == 0 + then flopS destF $ \ flops -> run (f `mappend` F flops flops) + else flopS destF $ \ flops -> run (f `mappend` F (-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 }}} **or** by building with `-fno-full-laziness` provided that `flopp` and `swap` are moved out of `flop` to the top level (otherwise, those allocate instead). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #917: -O introduces space leak
by GHC 27 Aug '13

27 Aug '13

#917: -O introduces space leak -------------------------------------+------------------------------------ Reporter: claus.reinke@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.5 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 rwbarton): * cc: rwbarton@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/917#comment:16> 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 26 Aug '13

26 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 nh2): Replying to [comment:31 parcs]: > nh2: That's an interesting idea. We would just have to persist the timing information somehow (through the interface file maybe) I don't think the interface file is a good place: I tried to build/improve Haskell build systems in the last months and interface files not being generated the same for identical inputs was always a problem (e.g. in http://ghc.haskell.org/trac/ghc/ticket/8144) Probably making an own file for that will work as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:33> 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 26 Aug '13

26 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 parcs): https://github.com/parcs/ghc/commits/ghc-parmake-gsoc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0