id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
4301	Optimisations give bad core for foldl' (flip seq) ()	daniel.is.fischer		"I'm not sure whether it's one freak case or a symptom of a problem that occurs more often. Compiled with optimisations, the code
{{{
foo :: [a] -> ()
foo = foldl' (flip seq) ()
}}}
produces the core
{{{
Rec {
FSeq.foo1 :: forall a_af0. [a_af0] -> (##)
GblId
[Arity 1
 NoCafRefs
 Str: DmdType S]
FSeq.foo1 =
  \ (@ a_af0) (w_sg9 :: [a_af0]) ->
    case case w_sg9 of _ {
           [] -> GHC.Unit.();
           : x_afz xs_afA ->
             case x_afz of _ { __DEFAULT ->
             case FSeq.foo1 @ a_af0 xs_afA of _ { (# #) -> GHC.Unit.() }
             }
         }
    of _ { () ->
    GHC.Prim.(##)
    }
end Rec }
}}}
for the worker (ghc-6.12.3, similar core from HEAD). Due to the boxing and unboxing between (##) and (), there's a case on the recursive call, hence it produces a stack overflow on long enough lists.

The problem was reported in http://www.haskell.org/pipermail/beginners/2010-September/005287.html, my attempt at understanding it here: http://www.haskell.org/pipermail/beginners/2010-September/005293.html.

So far, I've only managed to produce it for the very special combination of foldl' (flip seq) and a single (non-bottom) value datatype; any other function to be folded or a multiple value type produce a tail-recursive two-argument worker.

Nevertheless, on the off chance that it's a symptom of a real problem, I'm reporting it."	bug	new	low	7.6.2	Compiler	6.12.3			michal.palka@…	Unknown/Multiple	Unknown/Multiple	Runtime performance bug