[m-dev.] [Mercury-Language/mercury] Segfault in only Mercury after solutions in a particular code path (#72)
Zoltan Somogyi
zoltan.somogyi at runbox.com
Tue Aug 27 08:29:57 AEST 2019
On Mon, 26 Aug 2019 15:00:55 +1000, Peter Wang <novalazy at gmail.com> wrote:
> Unfortunately the problem is not limited to unify predicates, as in the
> attached test case.
Yes, you are right. That leaves changing the arg passing convention
the only feasible approach.
> We may need to disable the direct arg optimization
> until the calling convention can be changed.
Agreed. The attached diff makes that possible.
The option it adds *must* be set consistently in *all* the modules of a program,
including the standard library, so flipping the switch from the current backward-
compatible "yes" to "no" is a significant user-visible change, but then again,
changing the calling convention for predicates with direct-arg arguments
is a user-visible change as well, so we have to bite at least one of those bullets
sometime. Any opinions on which, and when?
Note that we should remove the "where direct_arg is" syntax on type definitions
sometime, since the compiler can now do at least as good a job as humans
at deciding when the optimization is applicable (provided it is switched on, of course).
Flip-the-switch time would be as good a time as any for this, which makes *now*
a good time for its deprecation.
On a tangentially related topic: I want to add both test cases to the suite,
but intend to add them under the name gh72a.m and gh72b.m. We have been
naming test cases bugN.m for Mantis bug N for a long time. Github bug reports
started much more recently, so they are going over numbers that Mantis has
already gone over. Naming test cases from github ghN.m will avoid clashes.
There is already a gh65.m in tests/valid. Any objections to using this naming
convention from now on?
Also, Julien, would you object to commenting out the test_generic_ref test case?
All other tests that we know we can't pass in any grade are commented out
in the relevant test directory's Mmakefile; why is this test treated differently?
Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.ada
Type: application/octet-stream
Size: 203 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20190827/86a53fa1/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.ada
Type: application/octet-stream
Size: 3818 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/developers/attachments/20190827/86a53fa1/attachment-0001.obj>
More information about the developers
mailing list