Mercury Bugs - mercury
View Issue Details
0000154mercuryBugpublic2010-06-29 14:062010-08-25 13:58
Reporterwangp 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000154: compiler abort with debugging enabled
DescriptionCompiler aborts on test case with debugging enabled.
TagsNo tags attached.
Attached Files? some_bug.m (3,925) 2010-06-29 14:06
https://bugs.mercurylang.org/file_download.php?file_id=101&type=bug

Notes
(0000269)
wangp   
2010-06-29 14:07   
% mmc --debug --allow-stubs -C some_bug.m
% Uncaught Mercury exception:
% Software Error: map.lookup: key not found
% Key Type: term.var(parse_tree.prog_data.prog_var_type)
% Key Value: var(10)
% Value Type: ll_backend.var_locn.var_state
% Stack dump follows:
% 0 pred exception.throw/1-0 (erroneous) (exception.m:411)
% 1 pred require.error/1-0 (erroneous) (require.m:122)
% 2 pred require.report_lookup_error/3-0 (erroneous) (require.m:98)
% 3 pred map.lookup/3-0 (det) (map.m:721)
% 4 pred ll_backend.var_locn.actually_place_var/7-0 (det) (var_locn.m:1380)
% 5 pred ll_backend.var_locn.var_locn_place_var/6-0 (det) (var_locn.m:1366)
% 6 4* pred ll_backend.var_locn.actually_place_vars/5-0 (det) (var_locn.m:1361 and others)
% 10 pred ll_backend.var_locn.var_locn_place_vars/5-0 (det) (var_locn.m:1353)
% 11 pred ll_backend.code_info.setup_call/6-0 (det) (code_info.m:3981)
(0000280)
wangp   
2010-08-25 13:14   
The problem goes like this: after switch detection the nested disjunction is converted to a switch, and some of the code is duplicated into the switch arms. Within the duplicated code is a call to get_arg, which is existentially typed, so the type_info output argument is renamed away in one of the switch arms.

When liveness.m works on the call to get_arg, it needs to complete the argument list with type_info variables. But the type_info_varmap only knows about the original type_info variable, not the renamed one, so the argument list is completed with the wrong type_info variable.
(0000281)
zs   
2010-08-25 13:58   
When the compiler duplicates code, it should call clone_variables in goal_util to clone the variables local to the goal, and clone_variables should take the rtti_varmaps as a parameter, and should update it as necessary. I think this means that if the typeinfo var (say V1) for a cloned var (say V2) is also duplicated, then the typeinfo var for the clone of V2 should be recorded as the clone of V1. On the other hand, if V2 is cloned but V1 is not (which in this case means that the type of V2 was established before the switch), then the current behavior is what you want.

Issue History
2010-06-29 14:06wangpNew Issue
2010-06-29 14:06wangpFile Added: some_bug.m
2010-06-29 14:07wangpNote Added: 0000269
2010-08-25 13:14wangpNote Added: 0000280
2010-08-25 13:58zsNote Added: 0000281