Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000103mercuryBugpublic2009-09-14 12:172011-03-08 21:33
Reporterwangp 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
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.
Relationships
Attached Files? lco_bug.m (1,235) 2009-09-14 12:17
https://bugs.mercurylang.org/file_download.php?file_id=79&type=bug

Notes
(0000315)
zs   
2011-03-08 21:33   
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.

Issue History
Date ModifiedUsernameFieldChange
2009-09-14 12:17wangpNew Issue
2009-09-14 12:17wangpFile Added: lco_bug.m
2009-09-14 12:18wangpStatusnew => assigned
2009-09-14 12:18wangpAssigned To => zs
2011-03-08 21:33zsNote Added: 0000315
2011-03-08 21:33zsStatusassigned => resolved
2011-03-08 21:33zsResolutionopen => fixed