[MLton] starting builds

[Wesley W. Terpstra]

On Aug 30, 2005, at 12:08 AM, Stephen Weeks wrote:
> You can pick any one of them, the smaller the better, compile with
> -keep g, and use gdb to find the line in the generated C code where
> the bus error occurs.

Since I can't run MLton on hppa at all atm, -stop g is my only option.
flat-array.3 is the smallest, but it worked with -align 8. Thus, I am  
going
to look at bytechar which seems the simplest that fails with both 4&8.

>  I'm betting on an alignment issue.

Yet the same mlton-compile binary which used to work now doesn't.
Maybe the new 2.6 kernel doesn't attempt to fix alignment problems?

Well, to test your theory, I built with -align 8 as well, that fixed  
several
of the regressions, but not all.

> You might also compile -debug true, which will link with a runtime
> with asserts turned on.

I built bytechar.sml with:
kiwi:~/src/mlton/test terpstra$ mlton -keep-pass ".*" -target hppa - 
stop g -debug true -verbose 3 bytechar.sml
... scp ...
terpstra@paer:~/new/mlton-20050826/test$ gcc -o foo -w -g -O0 -I ../ 
build/lib/include -L ../build/lib/self bytechar.?.c -lmlton -lgmp - 
lgdtoa -lm

(gdb) run
Starting program: /home/terpstra/new/mlton-20050826/test/foo

File bytechar.sml: Testing structures Byte and Char...
test1           OK
test2           OK
test3           OK
test4           OK
test5           OK
test6           OK
test7           OK
test8           OK
test9           OK
test10a         OK
test10b         OK
test10c         OK
Program received signal SIGSEGV, Segmentation fault.
0x00017678 in Chunk1 () at bytechar.1.c:1550
1550            Raise ()

I've placed a dump of all the passes (and output C) at:
http://www.terpstra.ca/test.tar.bz2

I tried array.sml as well:
#0  0x00016b10 in Chunk1 () at array.1.c:1298
1298            Raise ();
(gdb) l
1293            S(Word32, 8) = W32_1;
1294            Return ();
1295    L_188:
1296    L_195:
1297            GPNR(0) = 0x5;
1298            Raise ();
1299    L_187:
1300            goto L_195;
1301    default:
1302            W32_1 = O(Word32, S(Pointer, 0), 0);

Contrast this to a test that worked using -align 8, flat-array.3.sml:
1364            O(Real64, W32_2, 0) = R64_0;
(gdb) l
1359            Return ();
1360    L_401:
1361            R64_0 = WordS32_toReal64 (W32_0);
1362            W32_1 = WordU32_mul (W32_0, 0xC);
1363            W32_2 = Word32_add (S(Pointer, 4), W32_1);
1364            O(Real64, W32_2, 0) = R64_0;
1365            W32_3 = WordU32_mul (W32_0, 0xC);
1366            W32_4 = Word32_add (S(Pointer, 4), W32_3);
1367            O(Word32, W32_4, 8) = W32_0;
1368            W32_5 = Word32_add (0x1, W32_0);
(gdb) print R64_0
$1 = 1
(gdb) print &R64_0
$2 = (Real64 *) 0xc01f4cc8
(gdb) print W32_2
$3 = 4160760116
(gdb) print W32_2%8
$4 = 4

So, it seems there are two problems:
1. 8 byte reals need to be 8 byte aligned.
2. Raise() segfaults