2024-12-10 10:45 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000033mercuryBugpublic2008-03-26 15:36
Reportermaclarty 
Assigned Tomark 
PrioritynormalSeveritymajorReproducibilityalways
StatusassignedResolutionopen 
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

-Relationships
+Relationships

-Notes

~0000066

wangp (developer)

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.

~0000067

wangp (developer)

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.

~0000068

zs (developer)

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.

~0000069

zs (developer)

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.
+Notes

-Issue History
Date Modified Username Field Change
2007-12-20 15:54 maclarty New Issue
2007-12-20 15:54 maclarty 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
+Issue History