August 2013 - ghc-tickets

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

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): nh2: That's an interesting idea. We would just have to persist the timing information somehow (through the interface file maybe) and implement a smart semaphore (replacing QSem) that wakes up the module that would result in the shortest compile time. It certainly ''sounds'' possible, at least. Simon: Import loops were indeed not handled correctly. I managed to work out a solution that I hope is understandable. It involves augmenting a module's explicit textual dependencies with the implicit dependencies that arise from module loops. Let me know what you think. Other changes I made: 1. removed the `BinIO` constructor as suggested 2. more thoroughly commented the `FastString` implementation, as suggested. 3. revised one of the thread-safety changes: originally, I changed `newUnique` and `newUniqueSupply` to atomically update the `env_us` var. But the only reason this was necessary is because the `env_us` var was shared among interleaved threads created by `forkM`. So instead of making sure to atomically update this var, I think it is more sensible to not share the `env_us` var among interleaved threads. This solution should be in theory more efficient as well, as multiple threads are no longer potentially contending on the same `env_us` var. 4. and I enabled buffering of stdout/stderr when compiling modules via GHCi Please perform a second pass on all the commits, as I did a lot of rebasings and fixups etc and I might have missed something stupid. I have not yet fixed the IO manager bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/910#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented
by GHC 26 Aug '13

26 Aug '13

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented -------------------------------+--------------------------- Reporter: cjwatson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+--------------------------- Comment (by RoboTux): Replying to [comment:4 RoboTux]: > Inlining the call of the cacheflush system call (the call behind {{{__clear_cache}}}) should work but it means the cache would be flush every time mkJumpToAddr is called. I don't know enough the context of the code generation but if that function is called several time after 1 code generation then it's suboptimal. The patch then become: > > > {{{ > +#elif arm_TARGET_ARCH > +type ItblCode = Word32 > +mkJumpToAddr a > + = [ 0xe92d0080 -- push {r7} > + , 0xe3a0780f -- mov r7, #983040 ; 0xf0000 > + , 0xe2877002 -- add r7, r7, #2 > + , 0xe3a02000 -- mov r2, #0 > + , 0xef000000 -- swi 0x0 > + , 0xe8bd0080 -- pop {r7} > + , 0xe51ff004 -- ldr pc, [pc, #-4] # pc reads as <current insn>+8 > + , fromIntegral (ptrToInt a) ] > }}} I tried the patch on a Debian arm porterbox and it seems to work as no exception was raised with it while an exception was raised without it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7794#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0