[m-dev.] argument packing

Julien Fischer jfischer at opturion.com
Thu May 17 12:11:28 AEST 2018

On Thu, 17 May 2018, Zoltan Somogyi wrote:

> On Wed, 16 May 2018 10:36:47 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote

>>      Making Mercury/css/thread.mvar.cs
>>      Making Mercury/css/thread.semaphore.cs
>>      Making mer_std.dll
>>      ** Error making `mer_std.dll'.
>>      Mercury/css/erlang_rtti_implementation.cs(740,113): error CS0029: Cannot
>>      implicitly convert type `int' to `mercury.runtime.DuArgLocn'
>>      Mercury/css/erlang_rtti_implementation.cs(741,3): error CS0029: Cannot
>>      implicitly convert type `int' to `mercury.runtime.DuArgLocn'
>>     ... <more snipped>
>>      Mercury/css/erlang_rtti_implementation.cs(1445,30): error CS1729: The type
>>     `mercury.erlang_rtti_implementation.Maybe_pseudo_type_info_0.Pseudo_1'
>>      does not contain a constructor that takes `0' arguments
>>      ... error log truncated, see `mer_std.err' for the complete log.
>>      gmake[1]: *** [libmer_std.install] Error 1
> That, and its Java equivalent in your following email, was almost certainly
> caused by the optimization accidentally being left *on*. Please try the
> attached diff, which turns them off in high-level-data grades. For me,
> it generates the same code for tools/make_java_csharp_diff
> as a compiler I installed on 2018 may 2, but that is not as though
> a test as a bootcheck. I intend to commit it sometime tomorrow
> (minus the change to options.m) if it passes further bootchecks.

I've just bootchecked the Java grade with the attached diff applied.
(I'll do the C# one shortly, but I expect that it should now work too.)


More information about the developers mailing list