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,,,,,