#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
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
