[m-rev.] C# bootcheck

[Julien Fischer]

On Tue, 18 Jun 2019, Peter Wang wrote:

> On Tue, 18 Jun 2019 11:52:16 +0200 (CEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> My bookcheck in the C# grade yielded a few more (78) test failures,
>> which were in line with my expectations after the Java bootcheck.
>> 
>> The attached diff (which I have committed) should fix a few of these
>> for both Java and C#. I will see if I can reduce the number of unexpected failures
>> further not just by fixing the compiler problems causing them, but also
>> by disabling tests that these grades cannot pass (for now, at least),
>> or by listing them as expected failures in these grades. Are there
>> any objections?

Not from me.

>> 
>> One problem is that tools/bootcheck -jN does not seem to work
>> for Java and C#. When I try it, then Out.cs_parallel shows that
>> I get errors like this:
>> 
>> Making Mercury/int3s/mer_std.int3
>> Making Mercury/int3s/mer_std.int3
>> Making Mercury/int3s/mer_std.int3
>> ** Error making `Mercury/int3s/mer_std.int3'.
>> cp: cannot stat 'Mercury/int3s/mer_std.int3.tmp': No such file or directory
>> Error creating `Mercury/int3s/mer_std.int3': can't open input file: No such file or directory
>> Error: problem updating interface files.
>> 
>> Am I right in guessing that this is caused by bugs in mmc --make when invoked
>> in parallel mode? If yes, this seems like a fundamental bug that would warrant
>> disabling parallel mode until fixed. If not, does anyone know at least roughly
>> what part of the system is going wrong? It is pretty annoying to have a new
>> 6-core laptop and not being able to use 5 of them :-(
>
> Parallel mmc --make is not known to be buggy, no. Certainly we use it
> all the time with C grades.

I also use parallel mmc --make regularly (including with the Java grade)
have not encountered any problems like the above with it.

> Does the problem occur if you invoke mmc --make outside of bootcheck or
> mmake --use-mmc-make?

I would be particularly suspicious of --use-mmc-make.

>> Something else that concerns me are the differences between the C# source files
>> in stages 2 and 3. Out.cs.gz shows that pretty much all of these are concerned
>> with numbers at the extreme edge of representability, like this:
>> 
>> --- stage2/compiler/Mercury/css/ml_backend.mlds_to_java_data.cs 2019-06-18 01:21:06.220434988 +0200
>> +++ stage3/compiler/Mercury/css/ml_backend.mlds_to_java_data.cs 2019-06-18 01:53:18.045123091 +0200
>> @@ -11837,7 +11837,7 @@
>>        if (succeeded)
>>        {
>>          int Var_15 = 0;
>> -        int Var_16 = unchecked((int) 0xffffffff);
>> +        int Var_16 = -1;
>>          string Var_20 = null;
>>          string Var_21 = null;
>> 
>> My guess is that the condition of output_int_const_for_csharp is behaving differently
>> when compiled in hlc.gc than when compiled in csharp grade. Can anyone who speaks
>> C# more fluently than me verify this? And maybe fix that difference?
>
> The behaviour of output_int_const_for_{java,csharp} depends on the width
> of the Mercury `int' type, for the reason given in the comment in
> output_int_const_for_java.

Why the above is releveant here is that compilers built in the chsarp
and java grades are effectively 32-bit compilers; the hlc.gc is almost
certainly 64-bit.   (Given some of the design choices baked into the
JVM, 32-bits is the correct choice for Java at least.)

Julien.