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.