[MLton] MinGW + x86_64

[Matthew Fluet]

> On May 11, 2006, at 1:56 PM, Matthew Fluet wrote:
>> That would have been my first hypothesis as well, but it is incorrect. The 
>> IL dump does say where the type error occurred; it is the first few lines 
>> of the dump before "let exception Bind ...".  I see from the dump that the 
>> XML type-checker is complaining about:
>> 
>>    val IRGRP: word32 =
>>       0x20
>>    val irgrp: word16 =
>>       IRGRP
>> 
>> However, if I look at the core-ML code before the defunctorize pass, I see:
>> 
>>   val IRGRP: word16 = 0x20,
>> 
>> So, for some reason, the defunctorize pass is changing the type of IRGRP 
>> (and other constants) from word16 to word32.  That isn't the behavior I 
>> expect.
>
> This problem also occures on osx, after I tweak the signedness there to get 
> it to compile. It really works under linux?? :-) Any idea what might cause 
> this? I have never touched anything as deep in the compiler as the XML IL...

I should have mentioned that I was able to diagnose the problem; the 
elaborate phase really produces two types for every expression.  One is a 
genuine Standard ML type used to type check the rest of the program.  One 
is an 'internal' type that is used to propagated through to the typed ILs.

What's going on with the constants is that the two types are not 
guaranteed to be equivalent (given that the 'internal' type is some 
translation of the Standard ML type).  An expression form like:

   val IRGRP = _const "Posix_FileSys_S_IRGRP" : C_Mode.t;

causes the compiler to lookup the value of the constant in the 
build/lib/<target>/constants file.  The elaborate pass uses C_Mode.t as 
the Standard ML type to type-check the rest of the program; it is 
correctly determined by the basis-library/config/c/<targat>/c-types.sml 
bindings.  However, the 'internal' type is produced by the lookup constant 
function, which is in mlton/main/lookup-constant.fun.  From this file, one 
can see that it always produces constants with WordSize.default and 
RealSize.default sizes; furthermore, these defaults are hard-wired into 
the compiler, they are not determined by the (new) -default-type option, 
which sets the binding for the Int, Word, and Real structures in the Basis 
Library.

The reason it works under Linux is that mode_t is 32 bits, and so happens 
to line up with the WordSize.default.