[GHC] #5262: Compiling with -O makes some expressions too lazy and causes space leaks

[GHC]

#5262: Compiling with -O makes some expressions too lazy and causes space leaks
---------------------------------+------------------------------------------
    Reporter:  michal.palka      |       Owner:                                  
        Type:  bug               |      Status:  new                             
    Priority:  normal            |   Component:  Compiler                        
     Version:  7.1               |    Keywords:  laziness, strictness, space leak
    Testcase:                    |   Blockedby:                                  
          Os:  Unknown/Multiple  |    Blocking:                                  
Architecture:  Unknown/Multiple  |     Failure:  Incorrect result at runtime     
---------------------------------+------------------------------------------
 Here are some expressions that are executed in a too lazy way when
 optimisation is turned on in GHC. GHC is known to make some expressions
 too lazy when full laziness is turned on (as in #917), and indeed some of
 these expressions execute correctly when you add -fno-full-laziness.
 However, some of them are compiled too lazy even if -fno-full-laziness is
 present.

 Here are terms that get compiled too lazy with -O only when full
 strictness is on:
 {{{
 seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
 \a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int))
 (\b -> ([]::[] Int)) length
 \a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
 }}}

 Here are terms which are compiled too lazy with -O regardless of full
 strictness:
 {{{
 seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
 foldr (\a -> seq) id ((:) True (undefined::[] Bool))
 \a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool ->
 [] Int) a False
 \a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b ->
 (undefined::([] Bool))))
 map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool))
 (undefined::Int)))
 map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a ->
 undefined::Bool)))
 \a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b ->
 (undefined::Int -> [] Int)))
 }}}

 To discover the differences, just run the terms (whose types are [Int] ->
 [Int]) on some partially or fully-defined small lists.

 It is possible to construct programs which exhibit space leaks only when
 optimisation is turned on using some of these terms (examples attached).

 All programs have been tested with a pre-built GHC 7.1.20110606 on linux
 x86-64.

 Is this a bug? Well, full laziness comes with a disclaimer that some
 expressions will get too lazy, but this happens even when we turn off full
 laziness, so it might be a legitimate bug.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5262>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler