2024-04-17 07:52 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000103mercuryBugpublic2011-03-08 21:33
Reporterwangp 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0000103: bug in lcmc transformation
DescriptionThe compiler crashes on the given test case.

% mmc --optimize-constructor-last-call lco_bug
Uncaught Mercury exception:
Software Error: map.lookup: key not found
        Key Type: term.var(parse_tree.prog_data.prog_var_type)
        Key Value: var(2)
        Value Type: ll_backend.var_locn.var_state
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0000315

zs (developer)

If an argument in a recursive call is both a head variable AND
is used in a unification that we are trying to move before
the recursive call, like this:

  rec_call(..., HV2, X),
  HV3 = functor(HV2, X)

then each call through this recursive call site is next to a
unification that creates a cell with a field (in this case
the first field) that needs to be set to the value of HV2
finally computed by a base case. After the Nth recursive call,
there will be N cells. There is no way we can pass N addresses
to the base case without making the transformed code pass a
LIST of addresses in place of HV2 in the argument list.
That would be a different transformation than what lco.m does,
and it is far from clear that that transformation would be a
good idea, since it doubles the number of loop iterations
we would need to execute (N recursive calls, and N iterations
of a loop to fill in the fields).
  
The fix is to just disable the application of the lco
transformation to this call.

Fix committed 8 March 2011.
+Notes

-Issue History
Date Modified Username Field Change
2009-09-14 12:17 wangp New Issue
2009-09-14 12:17 wangp File Added: lco_bug.m
2009-09-14 12:18 wangp Status new => assigned
2009-09-14 12:18 wangp Assigned To => zs
2011-03-08 21:33 zs Note Added: 0000315
2011-03-08 21:33 zs Status assigned => resolved
2011-03-08 21:33 zs Resolution open => fixed
+Issue History