Mercury Bugs - mercury
View Issue Details
0000033mercuryBugpublic2007-12-20 15:542008-03-26 15:36
Assigned Tomark 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000033: Compiler abort when generating low level code
DescriptionRunning "mmc --make bug" on the attached source files results in the following abort from the compiler:

Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.prog_var_type)
        Key Value: var(81)
        Value Type: ll_backend.var_locn.var_state

The abort happens after:
% Generating low-level (LLDS) code for predicate `bug.test'/4 mode 0

Turning off all optimisations makes no difference.

I trimmed the test case down as much as I could, but any further changes seem to make the bug go away.

I'm using rotd-2007-12-19 on jupiter.
TagsNo tags attached.
Attached Files

2007-12-20 17:19   
I had a quick look at it. The bug is related to the fact that the second argument of the call to bug.load (TypeClassInfo_for_rdfStoreTStore_81) is not used elsewhere, so doesn't appear in the non-local set for that goal.
2007-12-20 17:39   
At 035-modecheck var(81) is not in the non-local set of the bug.load call as it is not used later. It also doesn't appear in the instmap delta.

After 110-lambda, var(81) *is* used later and does appear in the non-local set. But it is *not* in the instmap delta.
2007-12-20 19:07   
Instmap deltas are always restricted to the nonlocal set. The problem is the fact that the lambda transformation is including TypeClassInfo_for_rdfStoreTStore_81 in the argument list of the new lambda predicate, even though it isn't used. If it weren't there, then the construction of the closure wouldn't need its value.

The underlying problem, as so many times before, is the inclusion of typeinfos in typeclassinfos. The argument list of the lambda predicate includes variables of type S, therefore the typeinfo of type S must be included in the argument list.

In this case, TypeClassInfo_for_rdfStore_80 would be sufficient, but lambda.m does not know that. In fact, the relevant code in lambda.m, around line 354, does not seem to know about typeclassinfos as anything distinct from typeinfos at all. I think the short term fix would be to fix this state of affairs.

If mantis would let me, I would unassign myself from this bug.
2007-12-20 19:36   
Another possible fix would be, when restricting the instmap_delta of the original goal to its nonlocal set, to have mode analysis *notice* that it is deleting a typeinfo or typeclass info from the instmap delta, and to delete those variables from the rtti varmaps as well (since a typeinfo or typeclassinfo that isn't referred to anywhere doesn't do one any good in those maps). The right person for this fix would be Mark.

Issue History
2007-12-20 15:54maclartyNew Issue
2007-12-20 15:54maclartyFile Added: bug.tar.gz
2007-12-20 16:59zsStatusnew => assigned
2007-12-20 16:59zsAssigned To => zs
2007-12-20 17:19wangpNote Added: 0000066
2007-12-20 17:39wangpNote Added: 0000067
2007-12-20 19:07zsNote Added: 0000068
2007-12-20 19:36zsNote Added: 0000069
2008-03-26 15:36markAssigned Tozs => mark