Opened 9 years ago

Closed 9 years ago

#5028 closed bug (fixed)

stage3 build failing with core-lint error

Reported by: simonmar Owned by:
Priority: highest Milestone: 7.2.1
Component: Compiler Version: 7.1
Keywords: Cc: batterseapower, william.knop.nospam@…, simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Sometime around 10 March 2011, the nightly build on x86-64/Linux began failing the stage3 build with the following core-lint error:

*** Core Lint errors : in result of CorePrep ***
<no location info>:
    [RHS of ds4_s1PqX :: (FastString.FastString,
    Occurrence of a dead Id wild3_s1S4x
*** Offending Program ***
notHappyAtAll_r3z1 :: forall t_a5OH. t_a5OH
[GblId, Str=DmdType b]
notHappyAtAll_r3z1 =
  \ (@ t_a5OH) ->
    case GHC.Base.unpackCString# "Internal Happy error"
    of sat_s1Q0Y { __DEFAULT ->
    GHC.Err.error @ t_a5OH sat_s1Q0Y


while building compiler/stage3/build/Parser.hs.

Attachments (2)

NoBinderSwap.dpatch (101.7 KB) - added by batterseapower 9 years ago.
5028.dpatch (1.4 KB) - added by batterseapower 9 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by simonmar

I strongly suspect this patch:

Sat Feb 19 03:47:26 PST 2011  Max Bolingbroke <>
  * Drop dead core that was kept alive by RULES in CorePrep (#4962)

    M ./compiler/basicTypes/IdInfo.lhs +1
    M ./compiler/coreSyn/CorePrep.lhs -2 +68

almost nothing else went in around that time.

comment:2 Changed 9 years ago by simonpj

Cc: batterseapower added

Max, might you look at this, since it's your patch that's implicated?


comment:3 Changed 9 years ago by simonpj

See also #5017

comment:4 Changed 9 years ago by altaic

Cc: william.knop.nospam@… added

I confirmed that the core lint error from #5017 disappears after unpulling the aforementioned patch.

comment:5 Changed 9 years ago by batterseapower

It looks like this is because OccAnal implements binder-swapping. So if you have this in the input:

case x of y { p -> e[x] }

Then you get this in the output:

case x of y { p -> let x = y in e }

This makes y live, and if it was dead to begin with this causes a lint error. I had absolutely no idea OccAnal was playing games like this!

My first thought was that perhaps OccAnal should be setting the OccInfo on the "y" in it's manufactured binding to e.g. NoOccInfo. This would certainly make the error go away, but it is not in the spirit of OccAnal - as far as I can tell, OccAnal guarantees that *binders* will have the right OccInfo, but relies on the simplifier to ensure that the *occurrences* are up-to-date.

The obvious thing to do is paramaterise OccAnal so we can prevent it from implementing binder-swap when we use it just before CorePrep. I'm working on a patch to that effect.

Changed 9 years ago by batterseapower

Attachment: NoBinderSwap.dpatch added

comment:6 Changed 9 years ago by batterseapower

(Unvalidated) patch attached. A stage 3 build goes through OK with this -dcore-lint with this patch applied.

Does this look good to you, Simon? Or do you think there is a better approach?

comment:7 Changed 9 years ago by batterseapower

When I spoke to Simon about this last week we decided that it might be better to zap the OccInfo of the binder-swap let's RHS. However, I should point out that that would leave trivial bindings of the form (let x = y) in the input to the Core->STG passes, which might have negative performance implications.

comment:8 Changed 9 years ago by igloo

Mon Mar 21 04:00:09 PDT 2011
  * Fix Trac #5028: zap occ info when doing the binder swap

  This fixes the Lint error, but still risks leaving stupid
  let { x=y } bindings in the code.  But no time to fix that
  today.  (Leave the ticket open for that reason.)

comment:9 Changed 9 years ago by simonmar

Cc: simonpj added

Apparently Simon's patch didn't fix the bug. The stage3 build is still failing with the same core lint error.

comment:10 Changed 9 years ago by batterseapower

Simon's patch zaps the wrong case_bndr. The case_bndr returned by getProxies is the raw, unzapped, one from the Case expression being analysed. The robust solution is to zap the occinfo in wrapProxy itself.

I've attached a patch to HEAD that fixes the bug. I would have just pushed it but the repo is still locked.

Changed 9 years ago by batterseapower

Attachment: 5028.dpatch added

comment:11 Changed 9 years ago by simonpj

Eeek! Thank you for fixing this, Max.

The question of leftover bindings of form let x = y in ... remains, so we'll leave the ticket open for a fix for that.


comment:12 Changed 9 years ago by igloo

I've applied 5028.dpatch in git.

comment:13 Changed 9 years ago by simonmar

Resolution: fixed
Status: newclosed

This is now fixed, the stage3 builds are going through fine.

Note: See TracTickets for help on using tickets.