[MLton] Problem porting trunk to IA64/HP-UX

[Matthew Fluet]

> HP-UX 11.23 on IA64 is one of the platforms we need to support.  I
> tried to compile the new runtime on this platform.  Compilation failed
> with the compile time asserts in gc/int-inf.h; on this platform the
> GC_intInf and the contained anonymous struct will contain some padding
> by default.  This is probably for reasons of alignment and efficiency.

I suspect that on IA64, the GNU MP mp_limb_t type is 64-bits with 8 byte 
alignment.  I see a similar assertion on x86_64 when compiled with -m64.

I conclude from this that you are compiling on IA64 as a 64-bit 
executable.  This won't be supported by the compiler until the 64-bit 
port is completed.  I suspect that IA64 has a 32-bit compatibility mode 
(hopefully enabled by -m32), so I would add such a flag to the runtime 
flags for the time being.

> I fixed the runtime to compile by explicitly marking the structs
> packed with a GCC attribute:
> 
>   typedef struct GC_intInf {
>     GC_arrayCounter counter;
>     GC_arrayLength length;
>     GC_header header;
>     union {
>       struct {
>         mp_limb_t isneg;
>         mp_limb_t limbs[1];
>       } __attribute__((__packed__)) body;
>       pointerAux _p; /* alignment */
>     } obj;
>   } __attribute__((__packed__)) *GC_intInf;

This is the change I was planning on making for x86_64 as well.  So, I 
think it is fair to add it unconditionally.

> After this the runtime compiles cleanly.  I do get these warnings,
> however:
> 
>   gc/int-inf.h:20: warning: packed attribute causes inefficient alignment for 'isneg'
>   gc/int-inf.h:21: warning: packed attribute causes inefficient alignment for 'limbs'
>   gc/int-inf.h:22: warning: packed attribute causes inefficient alignment
>   gc/int-inf.h:15: warning: packed attribute causes inefficient alignment for 'counter'
>   gc/int-inf.h:16: warning: packed attribute causes inefficient alignment for 'length'
>   gc/int-inf.h:17: warning: packed attribute causes inefficient alignment for 'header'
>   gc/int-inf.h:24: warning: packed attribute causes inefficient alignment for 'obj'
>   gc/int-inf.h:25: warning: packed attribute causes inefficient alignment for 'GC_intInf'
> 
> But at least it compiles.  I think I'll just commit this unless anyone
> has objections.

I'm not surprised by the warning for 'isneg' and 'limbs', but I am a 
little surprised by the warning for 'counter', 'length', and 'header', 
which are all 32-bit words.  In any case, when one adds the packed 
attribute, on a 32-bit platform (e.g., x86-linux and x86-darwin), I get 
the warnings:

./gc/int-inf.h:20: warning: packed attribute is unnecessary for 'isneg'
./gc/int-inf.h:21: warning: packed attribute is unnecessary for 'limbs'
./gc/int-inf.h:22: warning: packed attribute is unnecessary
./gc/int-inf.h:15: warning: packed attribute is unnecessary for 'counter'
./gc/int-inf.h:16: warning: packed attribute is unnecessary for 'length'
./gc/int-inf.h:17: warning: packed attribute is unnecessary for 'header'
./gc/int-inf.h:24: warning: packed attribute is unnecessary for 'obj'
./gc/int-inf.h:25: warning: packed attribute is unnecessary for 'GC_intInf'

So, when we add the __packed__ attribute, we should also comment out the 
-Wpacked warning flag in runtime/Makefile.

> bin/add-cross went through OK.  But then, compiling mlton for the
> target platform with "mlton -stop g" failed, producing a rather large
> error message with 1259753 lines (yes, 1.26 million) and 48M size.  It
> starts like this:
> 
>   Type error: bad primapp
>   exp: WordVector_toIntInf (x_0)
>   val x_1 =
>      WordVector_toIntInf (x_0)
>   let
>      val x_1 =
>         WordVector_toIntInf (x_0)
>   in
>      x_1
>   end
>   ...
> 
> I am not familiar with the actual compiler code (I've just hacked the
> runtime so far) and don't really know where to start debugging this.
> 
> Does anyone have any ideas?  I can provide the error message file and
> others for download if needed.

Under which pass does the error arise?  You should try compiling with 
'-show-types true'.

However, I suspect that this is a consequence of trying to use a
64-bit representation without the proper compiler support; probably due 
to a mismatch between the Basis Library believing that IntInf should be 
represented by either an ObjPtr.t (= 64-bit integer (with low bit 1)) or 
a 64-bit pointer to a MPLimb.t vector (= Word64.word vector) but the 
compiler proper believing that IntInf should be represented by either a 
32-bit integer (with low bit 1) or a 32-bit pointer to a Word32.word 
vector.  The former is handled by 
basis-library/config/c/$(TARGET_ARCH)-$(TARGET_OS)/c-types.sml (for 
MPLimb.t) and basis-library/config/objptr/$(OBJPTR_REP) (for ObjPtr.t). 
  The $(OBJPTR_REP) basis library variable is set by the compiler to 
objptr-rep32.sml unconditionally, but will need to be handled according 
to the target platform.

You will probably have to stick with 32-bit compatibility mode until the 
completion of the 64-bit port.