bizarre strictness analysis bug

[simonmar]

This module:

module Test where

f :: Int -> Int -> Int
f 0 t = t
f i t = f (i-1) (t+1)

g :: Int -> Int -> Int
g 0 t = t
g i t = g (i-1) (t+1)

contains two identical functions, f and g. If we compile with -O2 -dverbose-core2core using HEAD, GHC derives different strictness for them:

Test.f [Occ=LoopBreaker]
  :: GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int
 ...
 Str=DmdType U(L)U(L)m,

Test.g [Occ=LoopBreaker]
  :: GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int
  ...
 Str=DmdType U(L)L,

The strictness on g is wrong (it should be strict in both arguments).

What is even more bizarre is that if you DELETE f, then g gets the correct strictness!

[simonpj]

Indeed a bizarre bug. But happily one that was easy to find and fix. The patch that introduced the bug was this one

Tue Oct 26 09:17:57 BST 2010  simonpj@microsoft.com
  * Fix initialisation of strictness in the demand analyser

This patch fixes it

Fri Jan 28 08:07:48 GMT 2011  simonpj@microsoft.com
  * Fix an egregious strictness analyser bug (Trac #4924)
  
  The "virgin" flag was being threaded rather than treated
  like an environment.  As a result, the second and subsequent
  recursive definitions in a module were not getting a
  correctly-initialised fixpoint loop, causing much worse
  strictness analysis results.  Indeed the symptoms in
  Trac #4924 were quite bizarre.
  
  Anyway, it's easily fixed.  Merge to stable branch.

    M ./compiler/stranal/DmdAnal.lhs -106 +123

Merge to stable. I don't think it's worth a regression test.

[igloo]

Merged