Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000539mercuryBugpublic2021-10-11 12:562021-10-14 13:17
Reporterwangp 
Assigned Tozs 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000539: placing nondummy var which has no state (LCMC)
DescriptionThe compiler aborts during code generation in low-level C grades when LCMC is enabled. (There are other similar bug reports involving debugging or parallel conjunction which may or may not be related.)


% mmc -s asm_fast.gc --optimise-constructor-last-call -C soupy
Uncaught Mercury exception:
Software Error: predicate `ll_backend.var_locn.actually_place_var'/6: Unexpected: placing nondummy var 6 which has no state
Stack dump follows:
   0 pred exception.throw/1-0 (erroneous) (exception.m:313)
   1 pred require.error/1-0 (erroneous) (require.m:172)
   2 pred require.unexpected/2-0 (erroneous) (require.m:203)
   3 pred ll_backend.var_locn.actually_place_var/6-0 (det) (var_locn.m:1807)
   4 pred ll_backend.var_locn.var_locn_place_var/5-0 (det) (var_locn.m:1706)
   5 pred ll_backend.var_locn.actually_place_vars/4-0 (det) (var_locn.m:1730)
   6 pred ll_backend.var_locn.var_locn_place_vars/4-0 (det) (var_locn.m:1722)
   7 pred ll_backend.code_loc_dep.setup_call/7-0 (det) (code_loc_dep.m:3325)
TagsNo tags attached.
Relationships
Attached Files? soupy.m (2,707) 2021-10-11 12:56
https://bugs.mercurylang.org/file_download.php?file_id=314&type=bug

Notes
(0001152)
zs   
2021-10-12 02:14   
I have diagnosed the source of the problem, and outlined two possible
approaches to a fix, in the version of this test case I added to
the test suite as tests/valid/bug539.m.

The bug is solely in lco.m, which sets a buried mine; the code generator,
which is where the abort occurs, merely steps on it.
(0001153)
wangp   
2021-10-12 11:46   
Thanks for looking into it.

Of the two proposed solutions, I favour the second. I don't see a reason why lco.m should be replacing the non-self-recursive call to type_check/2 with the lco-optimised version in the first place.
(0001154)
zs   
2021-10-12 18:53   
The reason why lco.m replaces the call to type_check in fun_type
is that these two predicates are mutually recursive, i.e. they are
in the same SCC. If we restricted lco.m to optimize only self-recursive
tail calls, lco couldn't generate code for mutually recursive predicates
that could handle unlimited input sizes in constant stack space.

lco.m should avoid transforming that call to type_check in fun_type
NOT because the call is not SELF-recursive, but because it is not
TAIL recursive (in the lco sense, i.e. modulo constructors).
A call that is a tail call in this sense *cannot* be followed by
consumers of the original output variable, which is the cause of the
compiler abort.
(0001155)
zs   
2021-10-14 13:17   
Fix committed 2021 oct 13.

Issue History
Date ModifiedUsernameFieldChange
2021-10-11 12:56wangpNew Issue
2021-10-11 12:56wangpFile Added: soupy.m
2021-10-12 02:14zsNote Added: 0001152
2021-10-12 11:46wangpNote Added: 0001153
2021-10-12 18:53zsNote Added: 0001154
2021-10-14 13:17zsAssigned To => zs
2021-10-14 13:17zsStatusnew => resolved
2021-10-14 13:17zsResolutionopen => fixed
2021-10-14 13:17zsNote Added: 0001155