[m-rev.] Compiler bug found

Zoltan Somogyi zoltan.somogyi at runbox.com
Sun Aug 6 00:47:34 AEST 2023


On 2023-08-04 20:29 +02:00 CEST, "Volker Wysk" <post at volker-wysk.de> wrote:
> I've found a bug in MMC rotd-2023-03-03. I've attached the compiler output
> and made a small example program.
> 
> Compile it with the mmc-make script. The bug doesn't occur when the option
> "-O 6" is left out.

I have started looking at this.

The problem occurs during a simplification pass on the amend predicate
When the pass tests whether the goal that is the whole body of amend can be
replaced by "true", part of the test is to see whether it changes the state
of the instantiation of any of the nonlocals. (This is the call to to instmap_delta_
no_output_vars in line 191 in simplify_goal.) I haven't zeroed in on the problem yet,
but I don't think the problem is in the mode checks so much as in the updating of the
merge inst table, because the immediate cause of the abort is a map.lookup
in that table failing. I suspect that somewhere, we are adding an entry to that table,
attaching the resulting merge-inst in an instmap delta somewhere, but throwing away
the updated merge inst table. That scenario would perfectly explain the symptom.

Attached are ARGSY, which is an argument list; invoking
"mmc `cat ARGSY`" generates the crash described in Volker's email. The output
of that invocation, from a somewhat-modified local debug-grade compiler
is in the other attached file, BAD_OUTPUT.

The optimization level is a red herring. The predicate the problem occurs in,
amend, is never called, so if dead proc elimination is enabled, it gets deleted
from the HLDS, and the crash never happens. If the optimization level is high
enough, then some compiler pass (e.g. deforestation) will invoke simplify
*before* dead proc elimination runs, but that compiler pass is NOT the cause
of the problem. I know that at -O0, with dead proc elim enabled (which is by default)
you don't get crash, but with dead proc elim explicitly disabled, you do.
In that last case, it is the pre-code-generation simplification pass that crashes.

The end-of-the-front-end simplify pass does not crash in any of the scenarios
I tested. It is possible that it is the culprit, setting up the conditions for a crash
on its next invocation.

If you want to try out ARGSY, you will need to update the paths in it.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ARGSY
Type: application/octet-stream
Size: 310 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230806/61c22254/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BAD_OUTPUT
Type: application/octet-stream
Size: 12500 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20230806/61c22254/attachment-0001.obj>


More information about the reviews mailing list