[MLton] Problem porting trunk to IA64/HP-UX
Matthew Fluet
fluet at tti-c.org
Sat Dec 23 22:52:55 PST 2006
> 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.
More information about the MLton
mailing list