August 2013 - ghc-tickets

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

29 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): wurmli, no I don't think it's reasonable. (Unless I'm missing something.) I have not looked very carefully, but I think this program does a lot of read/write of an imperatively-mutable `(STRef (Int,Int))`. If we could eliminate those read/write pairs altogether, that would indeed be a good thing, but that is pretty hard to do, because in principle any computation of type `(ST s a)` might mutate that reference. GHC simply doesn't have any serious optimisations for imperative code; it focuses on optimising functional code. To put it another way, what program would you expect GHC to transform your code into? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:14> 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 29 Aug '13

29 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: -------------------------------------+------------------------------------ Comment (by simonpj): Happy is ''part'' of the Haskell platform, so people installing HP will get a new GHC and a new Happy both. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4801: Typechecker performance regression 6.12 -> 7.0.1
by GHC 29 Aug '13

29 Aug '13

#4801: Typechecker performance regression 6.12 -> 7.0.1 --------------------------------------------+------------------------------ Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.0.2 Component: Compiler (Type checker) | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: perf/compiler/T4801 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by simonpj): peak-megabytes is a fragile number because it depends on when major GC strikes. I think I had to increase it on T4801 yesterday. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4801#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8160: sync-all failing to detect Windows
by GHC 29 Aug '13

29 Aug '13

#8160: sync-all failing to detect Windows ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | 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: | ------------------------------------+------------------------------------- See [http://www.haskell.org/pipermail/ghc-devs/2013-August/002102.html] The sync-all script tries to detect Windows but is failing. Also when the subsequent build fails to unpack `ghc-tarballs`, it somehow recovers and proceeds, leading to obscure subsequent fallout. Can't be hard to fix; but the fallout from failure is bad. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8175: Applicative instances for Ghc monad
by GHC 29 Aug '13

29 Aug '13

#8175: Applicative instances for Ghc monad ------------------------------------+------------------------------------- Reporter: DaniilFrumin | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, I propose the following change: Adding Applicative instances for Ghc monad and GhcT monad transformer: https://github.com/co-dan/ghc/compare/ghcapplicative? This can be useful, for example, in GHC API. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8175> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7266: Allow fractional-looking integer literals
by GHC 29 Aug '13

29 Aug '13

#7266: Allow fractional-looking integer literals -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 2245 -------------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged (with documentation) - thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7266#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7266: Allow fractional-looking integer literals
by GHC 29 Aug '13

29 Aug '13

#7266: Allow fractional-looking integer literals -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 2245 -------------------------------------+------------------------------------ Comment (by Austin Seipp <aseipp@…>): In [changeset:a6be6f1bd30c1476718392a259cfccf082d0da4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6be6f1bd30c1476718392a259cfccf082d0da4d" Implement -XNumDecimals (#7266) Under -XNumDecimals, it's possible to specify an integer literal using compact "floating point" syntax for any floating literal constant which also happens to be an integer. This lets us write 1.2e6 :: Integer instead of: 1200000 :: Integer This also makes some amendments to the users guide. Authored-by: Shachaf Ben-Kiki <shachaf(a)gmail.com> Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7266#comment:5> 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 29 Aug '13

29 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: -------------------------------------+------------------------------------ Comment (by thoughtpolice): OK, a few things: First, I believe there is a bug in the implementation of the warning in HEAD, such that it fails on some cases anyway. Like so: {{{ f1 :: Int# -> ByteArray# -> Int# f1 i ba = let !v = indexIntArray# ba i in v }}} this bug incorrectly trips a warning in `integer-gmp` which does something very similar. I believe the fix here is, in `TcBinds.lhs/checkStrictBinds`: {{{ ; warnTc (warnUnlifted && not bang_pat && lifted_pat) .... }}} should be: {{{ ; when lifted_pat $ warnTc (warnUnlifted && not bang_pat) .... }}} This is because in the above case, `lifted_pat` for `v` is false, as it's obviously not a lifted pattern, it's just a variable binder. However, that means that `(warnUnlifted && not bang_pat && lifted_pat)` overall is false, which causes `checkTc` to get angry. Instead we only want to ensure a bang pattern is there ''if'' `lifted_pat` is true. So, with that fixed, it fails in the stage2 build. Alex-3.0.5 seems fine and looks like it correctly generates lexers we can deal. But happy-1.18.10 does not: {{{ make -r --no-print-directory -f ghc.mk phase=final all HC [stage 1] compiler/stage2/build/Parser.o templates/GenericTemplate.hs:212:14: Pattern bindings containing unlifted types should use an outermost bang pattern: (sts1@((HappyCons (st1@(action)) (_)))) = happyDrop k (HappyCons (st) (sts)) In an equation for ‛happyMonadReduce’: happyMonadReduce k nt fn j tk st sts stk = happyThen1 (fn stk tk) (\ r -> happyGoto nt j tk st1 sts1 (r `HappyStk` drop_stk)) where (sts1@((HappyCons (st1@(action)) (_)))) = happyDrop k (HappyCons (st) (sts)) drop_stk = happyDropStk k stk templates/GenericTemplate.hs:219:14: Pattern bindings containing unlifted types should use an outermost bang pattern: (sts1@((HappyCons (st1@(action)) (_)))) = happyDrop k (HappyCons (st) (sts)) In an equation for ‛happyMonad2Reduce’: happyMonad2Reduce k nt fn j tk st sts stk = happyThen1 (fn stk tk) (\ r -> happyNewToken new_state sts1 (r `HappyStk` drop_stk)) where (sts1@((HappyCons (st1@(action)) (_)))) = happyDrop k (HappyCons (st) (sts)) drop_stk = happyDropStk k stk (off) = indexShortOffAddr happyGotoOffsets st1 (off_i) = (off +# nt) .... }}} where `GenericTemplate.hs` is included in all generated parsers. The error is correct in this case I believe, and the binding should be strictified; the defn is: {{{ #define FAST_INT Happy_GHC_Exts.Int# ... data Happy_IntList = HappyCons FAST_INT Happy_IntList ... }}} So we would need to make another point-release of `happy` that is compatible with GHC 7.8.1. SimonM, could you please weigh in here? Do you think we should still keep this warning since you closed #4304? I can contribute a patch to `happy` to fix this (it's relatively trivial,) but unfortunately it seems the ship has sailed on the platform versions of Happy working. OTOH, once you have the platform it is fairly easy to install a new version of Happy. Regardless of the decision to punt this or not for 7.8, I think the above misbehavior should still be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8022#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

29 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 wurmli): Replying to [comment:12 rwbarton]: > wurmli, what's the matter with it? > > "800,100,272 bytes allocated in the heap" means that the total size of all the allocations done over the course of the program is 800,100,272 bytes. That's the expected size of 20 million (Int, Int) pairs which share their second field (`n`), plus a small amount of other stuff. It doesn't have anything to do with the size of the heap at any given time. The maximum heap size is shown separately: "50,520 bytes maximum residency" which is quite reasonable. > > Similarly your original program does not ever occupy 10 GB of heap at a time. If you look at the process in top you will see a memory usage close to "47,184 bytes maximum residency" (well probably more like a couple MB, to hold the program image, but not anything near 10 GB). > > I have no idea why the original program timed out on the language benchmark machines, but it wasn't due to it allocating 10 GB sequentially. Allocation of short-lived objects is very cheap. But it is not free, and this discussion has been about why current GHC produces a program that allocates a lot when GHC 7.4 did not. Eliminating the large amount of allocation might reduce the runtime by a few percent or so. Would you agree that it is reasonable to expect the optimiser to optimise these allocations away? My simple assumption about the fannkuch program is that speed is enhanced if memory use stays local. The more only registers and cache are used the faster the program runs. With the repeated allocation of an intermediary variable the cache might be exhausted and the processor might have to copy in and out of cache what could slow down the program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7367#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8113: Cannot override ghci builtin commands with :def[!]
by GHC 28 Aug '13

28 Aug '13

#8113: Cannot override ghci builtin commands with :def[!] -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Easy (less than 1 Test Case: | hour) ghci/scripts/T8113 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by rwbarton): I suppose what I specifically want to happen when I enter a `:command` is an algorithm like this. If the name I entered is an exact match for a macro or built-in, use that name. Otherwise, try to complete the name to the name of a ''built-in'' in the traditional way. If this succeeds, use the resulting name. Otherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up. In all cases where we got a name, use the ''macro'' of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.) In other words, built-ins should take precedence over macros for the purpose of name ''completion'', but macros should take precedence over built-ins for the purpose of name ''lookup''. This is backwards- compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8113#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0