| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0000142 | mercury | Bug | public | 2010-04-06 15:07 | 2010-07-15 15:47 | ||||
| Reporter | wangp | ||||||||
| Assigned To | wangp | ||||||||
| Priority | normal | Severity | minor | Reproducibility | always | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | |||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0000142: problem updating rtti varmaps on inlining | ||||||||
| Description | In the following test case, higher order specialisation creates `or__ho1' from of `or'. We try to inline `or__ho1' into `orr'. In the call to `or__ho1' the same variable `TypeClassInfo_for_dcg_14' appears twice in the argument list, corresponding to the formal arguments V_22 and TypeClassInfo_for_dcg_18 in the callee. Eventually we try to rename the variables in the callee rtti varmap. We hit an assertion failure in apply_substs_to_constraint_map (hlds_rtti.m:777) as the two callee variables holding typeclass_infos map to the same variable in the caller, and supposedly it is for two different constraints. They are the same, just with different type variables. Is the fix to relax the assertion, or something else? | ||||||||
| Additional Information | % mmc --inline-single-use --optimise-higher-order dcg Uncaught Mercury exception: Software Error: hlds_rtti.m: Unexpected: inconsistent typeclass_infos 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 libs.compiler_util.unexpected/2-0 (erroneous) (compiler_util.m:88) 3 pred hlds.hlds_rtti.apply_substs_to_constraint_map/7-0 (det) (hlds_rtti.m:804) 4 pred tree234.foldl/4-0 (det) (tree234.m:2625) 5 pred map.foldl/4-0 (det) (map.m:962) 6 pred hlds.hlds_rtti.apply_substitutions_to_rtti_varmaps/5-0 (det) (hlds_rtti.m:679) 7 pred transform_hlds.inlining.do_inline_call/13-0 (det) (inlining.m:774) 8 pred transform_hlds.inlining.inlining_in_call/11-0 (det) (inlining.m:652) 9 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:558) 10 pred transform_hlds.inlining.inlining_in_conj/4-0 (det) (inlining.m:860) 11 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:571) 12 2* pred transform_hlds.inlining.inlining_in_conj/4-0 (det) (inlining.m:860 and others) 14 pred transform_hlds.inlining.inlining_in_goal/4-0 (det) (inlining.m:571) 15 pred transform_hlds.inlining.inline_in_proc/5-0 (det) (inlining.m:489) 16 3* pred transform_hlds.inlining.do_inlining/6-0 (det) (inlining.m:260 and others) 19 pred transform_hlds.inlining.inlining/2-0 (det) (inlining.m:249) 20 pred top_level.mercury_compile_middle_passes.maybe_do_inlining/6-0 (det) (mercury_compile_middle_passes.m:941) 21 pred top_level.mercury_compile_middle_passes.middle_pass/7-0 (det) (mercury_compile_middle_passes.m:189) 22 pred top_level.mercury_compile.mercury_compile_after_front_end/11-0 (det) (mercury_compile.m:1650) 23 pred top_level.mercury_compile.mercury_compile/11-0 (det) (mercury_compile.m:1582) 24 pred top_level.mercury_compile.compile/13-0 (det) (mercury_compile.m:1507) 25 pred list.map_foldl2/7-2 (det) (list.m:2359) 26 pred top_level.mercury_compile.compile_all_submodules/13-0 (det) (mercury_compile.m:1296) 27 pred top_level.mercury_compile.process_module_2/8-0 (det) (mercury_compile.m:1269) 28 pred top_level.mercury_compile.process_module/8-0 (det) (mercury_compile.m:1186) 29 pred top_level.mercury_compile.process_arg_2/8-0 (det) (mercury_compile.m:882) 30 pred top_level.mercury_compile.process_arg_build/10-0 (det) (mercury_compile.m:844) 31 pred make.util.build_with_module_options_args_invoked/12-0 (det) (make.util.m:987) 32 pred make.util.build_with_module_options_args/11-0 (det) (make.util.m:940) 33 pred top_level.mercury_compile.process_arg/8-0 (det) (mercury_compile.m:817) 34 pred top_level.mercury_compile.process_arg_list/10-0 (det) (mercury_compile.m:788) 35 pred top_level.mercury_compile.process_args/8-0 (det) (mercury_compile.m:740) 36 pred top_level.mercury_compile.process_all_args/8-0 (det) (mercury_compile.m:546) 37 pred top_level.mercury_compile.main_after_setup/7-0 (det) (mercury_compile.m:422) 38 pred top_level.mercury_compile.real_main_after_expansion/3-0 (det) (mercury_compile.m:308) 39 pred top_level.mercury_compile.real_main/2-0 (det) (mercury_compile.m:118) 40 pred top_level.main/2-0 (det) (top_level.m:56) | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
wangp (developer) 2010-04-21 11:54 |
I think the problem may be this. inlining.get_type_substitution, which is used in a few places, creates a substitution from the callee's head argument types to types in the caller. However, it doesn't account for type variables in the range of functional dependencies, so they never appear in the type substitution. So two separate type variables in the calleee remain as two different type variables after inlining, but they should have been unified. Which is why we got the assertion failure above: a single variable is supposedly holding the TypeClassInfo for two "different" constraints, but the two constraints only differ because their type variables weren't unified. Does that make sense? |
|
wangp (developer) 2010-07-15 15:47 |
committed a workaround 0000012:0000010 May |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-06 15:07 | wangp | New Issue | |
| 2010-04-06 15:07 | wangp | File Added: dcg.m | |
| 2010-04-21 11:54 | wangp | Note Added: 0000263 | |
| 2010-07-15 15:47 | wangp | Note Added: 0000277 | |
| 2010-07-15 15:47 | wangp | Status | new => resolved |
| 2010-07-15 15:47 | wangp | Resolution | open => fixed |
| 2010-07-15 15:47 | wangp | Assigned To | => wangp |
| Issue History |