[MLton] Sparc+linux

[Matthew Fluet]

> > and building the compiler with -exn-history true.  You'll get a slower
> > compiler, but you'll see the origin of the subscript exception.
>
> Done. I've attached the build log for hello.sml:
> val _ = print "Hello world\n"
>
> I don't see how a .sub exception is raised unless Vector.fold is broken.

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.  I guess there is something else out
there that is printing the history when an uncaught exception is raised,
because the history after the Error.bug line is the history when we
re-raised the exception after printing.

In any case, the history is pointing to a Subscript exception being raised
in the incLabelMeaning function of the shrinker, which indeed is doing
array sub and updates.  (The fact that exn-history is implemented via the
same mechanism that controls call profiling, the fact that we did not
compile with -profile-basis true is what prevented the history from diving
down into the basis library implementation to a manifest raise
expression.)

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

recompile the compiler (probably don't need -exn-history any more, but it
wouldn't hurt), and run the compiler with -diag-pass closureConvert.  This
ought to produce a hello-world.closureConvert.diagnostics file; the last
function in that file is the one that broke the shrinker.  Maybe there is
something there that sheds light on the problem.  Stephen knows the
shrinker much better than I, but that would be a good place to start.

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

I understand where your hunch is coming from, believing that the alignment
might impact the layout and representation of vectors, so that what was
once a valid subscript is now invalid.  However, -align 8 would only ever
make an array _bigger_, so every subscript remains valid.  But, more
importantly, the Subscript exception is raised by the Basis Library
implementation; the compiler does not insert bounds checks.  You can think
of it this way: the compiler provides length and unsafeSub, which the
Basis Library uses to implement safe subscripting.