#7802: kindFunResult in monad transformer
-------------------------------+--------------------------------------------
Reporter: tobsan | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler (Type checker)
Version: 7.6.1 | Keywords:
Os: Linux | Architecture: x86_64 (amd64)
Failure: Compile-time crash | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
This is probably related to the existing (fixed?) bug(s) about
kindFunResult, but better safe than sorry.
I was writing a brainfuck interpreter, and tried changing this code:
{{{
getptrval = gets mem >>= \a -> gets ptr >>= lift . readArray a
}}}
to this (which probably wouldn't even work):
{{{
getptrval = liftM2 (lift . readArray) (gets ptr) (gets mem)
}}}
which gives this error message from GHC:
{{{
Brainfuck.hs:53:21:ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-unknown-linux):
kindFunResult
<<details unavailable>>
}}}
Related type information:
{{{
type BFMonad a = StateT BFState IO a
data BFState = BF {
pc, ptr :: Int,
mem :: IOUArray Int Int,
program :: UArray Int Char
}
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7802>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#607: Ticky-ticky profiling
-------------------------------+--------------------------------------------
Reporter: simonmar | Owner: tim
Type: task | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: None
Resolution: None | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Difficult (2-5 days)
Testcase: | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
Comment(by nfrisby):
This seems to have been fixed at some point; ticky at least compiles. Are
we retaining this ticket for some reason?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/607#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7796: improve dead code elimination in CorePrep
-----------------------------+----------------------------------------------
Reporter: nfrisby | Owner: nfrisby
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.2 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related: #4962 #5433
-----------------------------+----------------------------------------------
#4962 is about generating code for (and allocating at runtime!) bindings
that are kept alive only by RULEs even though the RULEs are useless
downstream of .hi file generation.
Simon Marlow's patch for #5433 switched to a custom dead code eliminator,
since the "(case) binder swap" in OccurAnal was creating breaking some
code generator invariants.
However, that custom dead code generator doesn't do a dependency analysis,
so a letrec like this
{{{
let f = [g] \r [...] -> ...
g = [g] \r [...] -> ...
in ... g ...
}}}
is sent to the code generator ''without dropping'' `f`.
A patch to use a dependency analysis in CorePrep's dead code eliminator
improves allocation for several nofib programs (largest: cryptarithm2,
knights, fem).
{{{
Min -0.0% -4.2% -7.7% -7.7% -5.9%
Max +0.0% +0.0% +4.3% +4.3% +14.3%
Geometric Mean -0.0% -0.1% -0.2% -0.2% +0.2%
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7796>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#5550: GHC infinite loop when compiling vector
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: merge
Priority: low | Milestone: 7.6.2
Component: Compiler | Version: 7.2.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by amosrobinson):
* status: new => merge
Comment:
I have implemented Roman's suggestion of having an upper bound for
recursive types.
So in this example:
{{{
loop :: SPEC -> [Int] -> [Int] -> [Int]
loop SPEC z [] = z
loop SPEC z (x:xs) = loop SPEC (x:z) xs
}}}
The only good call pattern is
{{{loop SPEC (_:_) _}}}
but once that is specialised, there's another call pattern
{{{loop SPEC (_:(_:_)) _}}}
and so on.
So we just find the maximum number of recursive constructors in the
arguments, and if it's greater than the limit (default 3) we discard the
pattern.
I only check the recursive count if ForceSpecConstr is on for the current
function. This doesn't really matter, but if ForceSpecConstr isn't on it
should terminate anyway because of the max count.
Does this look OK to you, Roman?
https://github.com/ghc/ghc/commit/81d55a9ec28d9d7c8b1492516ebd58c5ff90c0e8
On Fri, Mar 8, 2013 at 7:20 PM, Roman Leshchinskiy <rl(a)cse.unsw.edu.au>
wrote:
> If you want to prevent infinite specialisation, then IMO the way
> to do it would be by not specialising more than a few times on
> recursive types but still specialising on tuples, Maybe, Either
> and friends as much as possible. That would guarantee termination
> without imposing an artificial bound.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5550#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
