[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.)
Julien.
More information about the developers
mailing list