[MLton] Code being dropped that shouldn't

[Wesley W. Terpstra]

I've been trying to track down the last bug in the library regression
test, but I think now it's not a bug in the test at all. Try an i386
compiler (windows and linux both show the same behaviour). Run:
./library-test -debug true -keep g -codegen c -profile time

Expected (wrong) output:
check starting up
libm5 starting up
libm4 starting up
libm3 starting up
libm2 starting up
libm1 starting up
m1 pointer test complete.
m2 pointer test complete.
m3 pointer test complete.
m4 pointer test complete.
m5 pointer test complete.
check pointer test complete.
check exits
profiling is on
profiling is on
profiling is on
profiling is on
profiling is on

The problem is that the atExit code for libm1-5 doesn't get run.
However, just adding a print statement to mlton/exit.sml:60:
               (* Return to 'lib_open'. *)
               val () = Primitive.MLton.Thread.returnToC ()
               (* Enter from 'lib_close'. *)
               val () = print "lib_close invoked\n"
               val _ = exiting := true
               val () = let open Cleaner in clean atExit end
               (* Return to 'lib_close'. *)
               val () = Primitive.MLton.Thread.returnToC ()
... changes the output to
check starting up
libm5 starting up
libm4 starting up
libm3 starting up
libm2 starting up
libm1 starting up
m1 pointer test complete.
m2 pointer test complete.
m3 pointer test complete.
m4 pointer test complete.
m5 pointer test complete.
check pointer test complete.
lib_close invoked
lib_close invoked
lib_close invoked
lib_close invoked
lib_close invoked
libm1 exits
libm2 exits
libm3 exits
libm4 exits
libm5 exits
check exits

So it seems that the library suffix doesn't get run until the print
statement is added. Tracing the execution of m5_close with gdb
confirms this. I know there's some sort of basis-specific code
elimination. Is it possible that librarySuffix is getting hit by this?