[m-rev.] C# bootcheck

[Peter Wang]

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?
> 
> 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.

Does the problem occur if you invoke mmc --make outside of bootcheck or
mmake --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.

Peter