[MLton] Sparc+linux

Wesley W. Terpstra terpstra@gkec.tu-darmstadt.de
Mon, 20 Dec 2004 02:08:45 +0100


On Sun, Dec 19, 2004 at 04:05:51PM -0500, Matthew Fluet wrote:
> > Done. I've attached the build log for hello.sml:
> > val _ = print "Hello world\n"
> 
> MLton raised in 35.56 + 6.68 (16% GC)
> shrinker raised unhandled exception: Subscript
> 	Shrink.shrinkFunction.anon.incLabelMeaning ssa/shrink.fun 249.7
> 
> No, the exn-history reified the control stack at the point where the
> exception was raised, then we printed it.  What is at the top of the
> history is what raised the exception. 

Ahh - I thought the line should be exactly where the .sub occured.
Thanks for your help with this; I would have no chance on my own.

> The next thing I would try would be to print out the to-be-shrunk function
> that is giving rise to the subscript exception.  To do so, I would modify
> closure-convert.fun line 687 to the following:
> 
> 	    val f =
> 	       Function.new {args = args,
> 			     blocks = Vector.fromList blocks,
> 			     mayInline = mayInline,
> 			     name = name,
> 			     raises = raises,
> 			     returns = SOME returns,
> 			     start = start}
> 	    val _ =
> 	       Control.diagnostics
> 	       (fn display => display (Function.layout f))
> 	    val f = shrinkFunction f

Unfortunately, I don't know this IL... are the MLton ILs documented?
I did a -diag-pass closureConvert with and without this patch and here's the
diff in the output (which corresponds to the EOF):

@@ -3907,33 +3907,3 @@
 x_3213 Type exn
 x_3214 Type word8 vector
 x_3215 Type unit
-fun x_3216 (env_0, x_3217) = L_0 ()
-  L_0 ()
-    x_3218 = MLton_bug (x_3)
-    raise (x_5)
-fun x_3219 (env_1, x_3220) = L_1 ()
-  L_1 ()
-    x_3221 = MLton_bug (x_12)
-    return x_3221
-fun x_3222 (env_2, x_3223) = L_2 ()
-  L_2 ()
-    x_3225 = #1 x_3223
-    x_3226 = #0 x_3223
-    x_3224 = MLton_equal (x_3226, x_3225)
-    return x_3224
-fun x_3227 (env_3, x_3228) = L_3 ()
-  L_3 ()
-    x_3230 = #1 x_3228
-    x_3231 = #0 x_3228
-    x_3229 = MLton_equal (x_3231, x_3230)
-    return x_3229
-fun not_2 (env_4, x_3232) = L_4 ()
-  L_4 ()
-    case x_3232 of
-      false => L_6 | true => L_7
-  L_7 ()
-    L_5 (x_37)
-  L_6 ()
-    L_5 (x_36)
-  L_5 (x_3233)
-    return x_3233

So, basically your patch adds all of these 'funs' to the end of the output.
I hope that you see something wrong with the last one. ;)

> > I'm going to try compiling the compiler with '-align 4' and see if the
> > problem disappears... call it a hunch. =)

Actually, my hunch didn't involve anything so deep as thinking about the
'why'. Rather, this is the only difference between the hppa and sparc
ports now that it's all using C99... and the hppa port works.

Anyways, it's a moot point:
/mnt/dm0/terpstra/cvs/build/lib/mlton-compile @MLton -- /mnt/dm0/terpstra/cvs/build/lib/world
make[1]: *** [world-no-check] Bus error

-- 
Wesley W. Terpstra