[MLton] cvs commit: C types now distinguish between signed and unsigned words

[Alexandre]

I will try, but I have compilation question.

======================================
CWD: ~/Applications/MLTon/mlton-20041109  Time: 09:59:59 Jobs: 0
  xlex@Karlson>make all-no-docs
make dirs runtime compiler world-no-check
mkdir -p /Users/xlex/Applications/MLTon/mlton-20041109/build/bin 
/Users/xlex/Applications/MLTon/mlton-20041109/build/lib/self 
/Users/xlex/Applications/MLTon/mlton-20041109/build/lib/include
Compiling MLton runtime system for self.
make -C runtime
zcat gdtoa.tgz | tar xf -
patch -p0 <gdtoa-patch
cd gdtoa && gcc -Wall -I. -Iplatform -D_FILE_OFFSET_BITS=64 
-fomit-frame-pointer -o arithchk.out arithchk.c
arithchk.c:140: warning: return type defaults to `int'
cd gdtoa && ./arithchk.out >arith.h
cd gdtoa &&                                     \
         gcc -Wall -I. -Iplatform -D_FILE_OFFSET_BITS=64 
-fomit-frame-pointer -O2                        \
                 -Dstrtod=gdtoa_strtod           \
                 -Dstrtof=gdtoa_strtof           \
                 -w -O1 -c -DINFNAN_CHECK        \
                 *.c
ar rc libgdtoa.a gdtoa/*.o
ranlib libgdtoa.a
gcc -Wall -I. -Iplatform -D_FILE_OFFSET_BITS=64 -fomit-frame-pointer 
-O2 -c -o basis/Array/numElements.o basis/Array/numElements.c
In file included from platform.h:38,
                  from basis/Array/numElements.c:1:
platform/darwin.h:26:36: /usr/local/include/gmp.h: No such file or 
directory
make[2]: *** [basis/Array/numElements.o] Error 1
make[1]: *** [runtime] Error 2
make: *** [all-no-docs] Error 2
=======================================================

Yes, I know - I need GMP library installed, which I do installed in 
/opt/local/ - how can I show this at the compilation time?


Regards,
/Alexandre.

On Jan 14, 2005, at 04:19, Matthew Fluet wrote:

>
>>> sweeks      04/09/06 17:46:20
>>>
>>>   Log:
>>>   MAIL C types now distinguish between signed and unsigned words
>>>
>>>   This distinction is necessary because on some platforms the calling
>>>   convention for signeds and unsigneds is different.  This can happen
>>>   when a small word (e.g. 8 bit) is represented in a larger word
>>>   (e.g. 32 bit), in which case the signed version will be passed sign
>>>   extended and the unsigned version will be passed zero extended.
>>
>> I don't believe that this modification had the intended effect.  In
>> particular, while we correctly distinguish between signed and unsigned
>> words for primitives, we do not do so for _import-ed functions.
>
> Could someone on a PPC please run this test with mlton-20041109?  
> Thanks.
> <test.tgz>