-O flag produces faulty code

[orenbenkiki]

The -O flag generates incorrect code in both 6.8.2 and 6.9.

I tested it myself on 6.8.2 - The -O flag causes the program to enter a 100% CPU endless loop

Heffalump also tested it on 6.9 - The -O flag causes it to segfault

Attached is a tgz file containing the code (and the input).

ghc --make -o obk Main.hs ; obk -> works

ghc --make -o obk -O Main.hs ; obk -> fails

[orenbenkiki]

Program failing to compile with -O

[ganesh]

I (Heffalump) only tried with 6.9.20080316, by the way, so it may yet be fixed more recently.

[igloo]

Copying the mtl and haskell-src code in and I can reproduce this with the HEAD:

$ happy Language/Haskell/Parser.ly
$ ghc  -fforce-recomp -XMultiParamTypeClasses -XFunctionalDependencies -XTypeSynonymInstances -XFlexibleInstances --make -O -o obk Main.hs
$ ./obk
[...]
Keep l_yaml_stream_F_0
obk: internal error: scavenge: unimplemented/strange closure type 28 @ 0x2adffca5c428
    (GHC version 6.9.20080606 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

[simonmar]

I'm on this one, looks like a problem with the thunk-selector machinery (again; surprise surprise).

[simonmar]

Fixed:

Tue Jul 29 16:05:18 BST 2008  Simon Marlow <marlowsd@gmail.com>
  * FIX #2327: a fault in the thunk-selector machinery (again)
  This program contains an expression of the form
  
     let x = snd (_, snd (_, snd (_, x)))
  
  (probably not explicitly, but that's what appears in the heap at
  runtime).  Obviously the program should deadlock if it ever enters
  this thing, but apparently the test program in #2327 never does.
  
  The GC tries to evaluate the snd closures, and gets confused due to
  the loop.  In particular the earlier fix for #1038 was to blame.