- ghc-tickets - Haskell.org

Re: [GHC] #5539: GHC panic - Simplifier ticks exhausted
by GHC 13 Dec '13

13 Dec '13

#5539: GHC panic - Simplifier ticks exhausted ---------------------------------------+---------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Changes (by ghorn): * cc: gregmainland@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5539#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8608: internal error: ARR_WORDS object entered!
by GHC 12 Dec '13

12 Dec '13

#8608: internal error: ARR_WORDS object entered! ----------------------------+---------------------------------- Reporter: Rothiph | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------- I'm using Windows 8.1 64-bit, the latest Windows SDK, and the latest Haskell Platform to rebuild a project. This project was previously building on Windows 7 64-bit with the same HP and a previous version of the Windows SDK. Source code for the project was unchanged, but my .cabal file was updated with different "extra-lib-dirs", "include-dirs", and "extra-libraries" fields. When running this program after a `cabal build` I see the following error: Segmentation fault/access violation in generated code Using print statements I was able to locate the error as occurring during a call to an external DLL function. I would assume this is a bug in my own code. Access violations are expected when misusing FFI, after all. However, I get a different error when compiling with profiling, and then executing with `Main.exe +RTS -xc`: Main.exe: internal error: ARR_WORDS object entered! (GHC version 7.6.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Coming up with a minimal example would take time, but I can do that if someone thinks there is a possibility of this being a GHC bug. Is it possible for this message to appear under normal circumstances by programmer error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8610: Rebuild on a definition-based granularity
by GHC 11 Dec '13

11 Dec '13

#8610: Rebuild on a definition-based granularity ------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ 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: | ------------------------------------+------------------------------------- Currently, GHC rebuilds modules whose mtime suggests they changed, and all dependent modules. This rebuilds *far* more than is actually necessary due to the change. For example, if a single definition changed in a module, only that definition needs to be rebuilt, and very few of the definitions in the dependent modules probably depend on it, so only they ought to be rebuilt. Another example, is temporarily checking out a different branch, and then going back to the master branch. In this case, the mtimes of many modules will change, but the content will remain the same. If definition-granularity changes were detected, rather than module- granularity, this scenario will rebuild nothing. This improvement could shorten the development cycle of all Haskell projects significantly, making Haskell a significantly more productive language to use on larger projects. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): Trac seems to think I write too much, just lost a somewhat long text here :-(. I was explaining why nested CPR kills a let-no-espcape in this code taken from `scs`’s `LinearAlgebra`: {{{ #!haskell v_zipWith :: (a -> b -> c) -> Array Int a -> Array Int b -> Array Int c v_zipWith f a b | compatible = listArray (bounds a) (zipWith f (elems a) (elems b)) | otherwise = error "error" where compatible = bounds a == bounds b }}} Point taken, I’ll be brief: CPR can kill the no-let-escape property; hence more CPR kills more of that. The problem occurs if the `$j` gets a more detailed CPR type than the expression it is part of, or the expression is somewhere where CPR w/w cannot happen (e.g. in an argument to `runStRep`). This problem is not new and some work-arounds for it exist in the current code (`[CPR for Sun types]`). But maybe this needs a generally better story. (Sidenote: Inlining `runSTRep` would have helped here, but was disabled by simonmar in 920dbbddf57ff02e0734943bb93dd4cecc5568e0/base.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): The numbers are a bit more interesting if I enabled nested CPR inside ''unboxed'' tuples, i.e. in code involving IO or ST: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- banner +2.1% +0.1% 0.00 0.00 +0.0% compress2 +2.0% +0.1% +11.5% +9.8% +20.8% expert +2.1% +0.1% 0.00 0.00 +0.0% fibheaps +2.0% -0.3% 0.05 0.05 +0.0% fluid +2.5% +0.1% 0.01 0.01 +0.0% gamteb +2.1% -0.2% 0.06 0.06 +0.0% grep +2.0% +0.1% 0.00 0.00 +0.0% infer +2.0% -1.2% 0.09 0.09 +0.0% k-nucleotide +1.5% -6.9% +0.1% +0.2% +0.0% maillist +2.1% -0.3% 0.10 0.12 +0.0% pic +2.2% -0.5% 0.01 0.01 +0.0% rfib +2.1% +0.1% 0.03 0.03 +0.0% scs +2.3% +0.2% +1.0% +1.4% +0.0% tak +2.1% -0.1% 0.02 0.02 +0.0% treejoin +2.1% +0.1% +0.0% +0.0% +0.0% wave4main +2.1% +11.3% -0.5% +0.0% -7.1% -------------------------------------------------------------------------------- Min +1.5% -6.9% -13.2% -13.3% -33.3% Max +2.5% +11.3% +16.5% +16.0% +20.8% Geometric Mean +2.0% +0.0% +0.2% +0.3% -0.3% }}} One particular good result (`k-nucleotide`), and one bad `wave4main`, and otherwise a slight general improvement. The change in `k-nucleotide`’s core is too large to spot the reason for the improvement. Diffing the `-ddump-simpl` of `wave4main` shows only one change. It stems from this function {{{ #!haskell tabulate :: (Int -> x) -> (Int, Int) -> Array Int x tabulate f (l,u) = array (l,u) [(i, f i) | i <- [l..u]] }}} where in the (inlined) `array` a worker for `go` gets its return type changed from `(# GHC.Prim.State# s_aTM, GHC.Arr.Array GHC.Types.Int x_aqE #)` to `(# GHC.Prim.State# s_aTM, GHC.Prim.Int#, GHC.Prim.Int#, GHC.Prim.Int#, GHC.Prim.Array# x_aqE #)`. Which looks good, but the worker is tail-recursive, and the boxing in the wrapper is not cancelled at the use site of `go`, so there is nothing gain by moving the constructor applications from the worker to the wrapper. But some isolated testing indicates that this costs 96 bytes of allocation per run, so I doubt that this is the main cause for the 11% increase; there might be something hidden in the libraries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): Here is a nother reason why nested CPR is not very successful: The requirement of definite termination is not easy to meet. One would think that the extended Euclidean algorithm is a good candidate for nested CPR: {{{ #!haskell extendedEu2 :: Int -> Int -> (Int, Int) extendedEu2 a 0 = (1, 0) extendedEu2 a b = (t, s - q * t) where (q, r) = quotRem a b (s, t) = extendedEu b r }}} but it is not: With a return type of `dm(d,dm(d))` we cannot do more than unbox the tuple. Now with a few iterations between the code and the core, one can find a strictness annotation that makes it work: With {{{ #!haskell extendedEu :: Int -> Int -> (Int, Int) extendedEu a 0 = (1, 0) extendedEu a b = let b' = s - q * t in b' `seq` (t, b') where (q, r) = quotRem a b (s, t) = extendedEu b r }}} we infer `dm(tm(d),tm(d))` and the worker gets type `GHC.Types.Int -> GHC.Prim.Int# -> (# GHC.Prim.Int#, GHC.Prim.Int# #)`. So likely nested CPR might help those who are careful to use strictness annotation and use strict data types (which some people are doing almost exclusively), but not a lot with the usual lazy programming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): It helps, i.e. removes all increases of Allocs (I don’t trust `cacheprof`, the allocations there seem to vary even from run to run): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- cacheprof +0.0% +0.2% +1.5% +0.9% -1.8% gamteb +0.1% -0.2% 0.06 0.06 +0.0% infer +0.0% -1.2% 0.09 0.09 +0.0% pic +0.0% -0.6% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.0% -1.2% -5.2% -5.2% -4.0% Max +0.6% +0.2% +3.3% +3.0% +9.1% Geometric Mean +0.0% -0.0% +0.1% +0.1% +0.0% }}} So on the one hand: Nice, no regression due to nested CPR, and some improvements (although very minor – is that even significant?) But the “fix” is not well-targeted, it rather is a heuristic. Unfortunately, I don’t see anything smarter to do here if we do not do whole-program compilation, or do not provide multiple implementations of the the function with varying degrees of CPRness. An alternative, not well-aimed fix would be to zap the CPR property for all top-level constants (and not just for thunks). This would make CPR much more robust against allocation increase, but that would prevent a lot of CPR where we really want it, i.e. where the constant is on the cold path and the unshared `Int#` cell is worth having an unboxed result type (i.e. in a naive `fac` function). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): Unfortunately, that was not it. The only visible change left is that `addtoLUT` in `Lisplikefns` is getting nestedly CPR’ed, without real gain (but also without loss, one would think). There is one other lead: With nested CPR, lots of "show" methods get a nested CPR property. E.g. the show method for `(,)` has now a return demand `tm2(tm(d),d)` (instead of `m2` as before), so the worker returns `(# GHC.Prim.Char#, [GHC.Types.Char] #)` instead of `(# GHC.Types.Char, [GHC.Types.Char] #)`, likely causing a re-boxing of the `(` character. I’ll disable nested CPR information inside a sum type to confirm this theory. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 10 Dec '13

10 Dec '13

#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): Found one possible reason for the allocation increase: boyer2 was losing a no-let-escape, because the insight from `Note [CPR for sum types]` was not applied inside a nested CPR result. Fixed that now, nofibs are running. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 09 Dec '13

09 Dec '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103, #7889 Blocking: 8530 | ----------------------------+---------------------------------------------- Comment (by 3noch): I just got this trying to load `libHSpersistent-sqlite-1.2.1.a`. Any idea when it will be solved? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0