|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000033||mercury||Bug||public||2007-12-20 15:54||2008-03-26 15:36|
|Target Version||Fixed in Version|
|Summary||0000033: Compiler abort when generating low level code|
|Description||Running "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.
|Tags||No tags attached.|
|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.|
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.
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.
|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.|
||File Added: bug.tar.gz|
|2007-12-20 16:59||zs||Status||new => assigned|
|2007-12-20 16:59||zs||Assigned To||=> zs|
|2007-12-20 17:19||wangp||Note Added: 0000066|
|2007-12-20 17:39||wangp||Note Added: 0000067|
|2007-12-20 19:07||zs||Note Added: 0000068|
|2007-12-20 19:36||zs||Note Added: 0000069|
|2008-03-26 15:36||mark||Assigned To||zs => mark|