0000033: Compiler abort when generating low level code

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000033

mercury

Bug

public

2007-12-20 15:54

2008-03-26 15:36

Reporter

maclarty

Assigned To

mark

Priority

normal

Severity

major

Reproducibility

always

Status

assigned

Resolution

open

Product Version

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.

Attached Files

Relationships

Relationships

Notes
~0000066 wangp (developer) 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.

~0000067 wangp (developer) 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.

~0000068 zs (developer) 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.

~0000069 zs (developer) 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.

Notes

Date Modified	Username	Field	Change
Issue History
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