[MLton] x86_64 branch runtime compiles on HPPA/HP-UX

[Matthew Fluet]

> The runtime compiles on HPPA/HP-UX.  I didn't have to touch anything
> but platform/hpux.[ch], so good job!

Great!

> I do get some warnings still, which I don't think can be cured in
> hpux.h.  We've seen these before, though:
>
> In file included from gc.c:38:
> gc/generational.c: In function 'createCardMapAndCrossMap':
> gc/generational.c:156: warning: cast increases required alignment of target type
> gc/generational.c: In function 'resizeCardMapAndCrossMap':
> gc/generational.c:180: warning: cast increases required alignment of target type
> In file included from gc.c:45:
> gc/int-inf.c: In function 'IntInf_toString':
> gc/int-inf.c:360: warning: cast increases required alignment of target type
> gc/int-inf.c:364: warning: cast increases required alignment of target type
> bytecode/interpret.c: In function 'interpret':
> bytecode/interpret.c:416: warning: cast increases required alignment of target type
> basis/Real/modf.c: In function 'Real64_modf':
> basis/Real/modf.c:10: warning: cast increases required alignment of target type

Yup, these all seem to be the same that Stephen saw on sparc-solaris; the 
bytecode/interpret.c:416 warning is "new", but it is due to the inlining 
of Real64_modf into the bytecode interpreter, so it is effectively the 
same.

> There are no other warnings left on HPPA/HP-UX.   All of these
> warnings seem to come from casting stuff to the `pointer' type.  Did
> we already come to a conclusion about what would be the best ways to
> get rid of these?

I don't think there are easy fixes for any of them, so I'm happy to live 
with them.  We should probably put comments into the respective files to 
note that they are benign.

BTW, the Real64_modf is a legitimate warning, since a program compiled 
with -align 4 might really have a 4-byte aligned double on a machine where 
doubles need to be 8-byte aligned.  As I noted before, we should handle 
this by using the 'Real64_{fetch,move,store}' functions from 'c-chunk.h', 
possibly further conditioned to only do the expensive stuff in the case of 
a truly misaligned double.

BTW, since HPPA is raising these warnings, then
'val handlesMisalignedReals' in 'mlton/codegen/c-codegen.fun' should 
probably be extended to handle HPPA.  You probably currently get a 
hardware exception if you try compiling and running a floating-point 
intensive application with -align 4 on HPPA/HP-UX.