-native self compile problems

[Matthew Fluet]

That's a known bug, with a really simple fix.  In x86-codegen.fun, the
outputAssembly function doesn't call  done ()  before it loops to a new
assembly file.  That leaves the file open and unflushed, which causes
these strange errors when the assembler hits it.  Here's the correct
version of the function:

        fun outputAssembly ()
          = let
              val split = !Control.Native.split
              fun loop chunks
                = let
                    val (print, done) = makeS()
                    val _ = List.foreach
                            (file_begin,
                             fn asm => print((Assembly.toString asm) ^ "\n"))
                    fun loop' (chunks, size) 
                      = case chunks
                          of [] => done ()
                           | chunk::chunks
                           => if (case split
                                    of NONE => false
                                     | SOME maxSize => size > maxSize)
                                then (done (); loop (chunk::chunks))
                                else loop'(chunks, 
                                           size + outputChunk (chunk, print))
                  in 
                    loop' (chunks, 0)
                  end
            in 
              loop chunks;
              x86Translate.translateChunk_totals ();
              x86Simplify.simplify_totals ();
              x86AllocateRegisters.allocateRegisters_totals ();
              x86Validate.validate_totals ()
            end


> Command exited with non-zero status 1
> 3101.24user 29.44system 52:12.79elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k

Interestingly, the total time is back to being reasonable.  I'm very
confused about this.  A self compile I ran over the weekend also finished
in under 2 hours.  Likewise for one I ran this morning.  And I've tried a
self-compile rolled back to the update I sent out last week (with the fix
above), also taking 2 hours.  There is a lengthy pause near the end of the
8th assembly file, but certainly nothing like what originally raised this
issue.

Because this bug isn't all that reproducible, I'm wondering if it might be
something else besides the native backend.  Could the  done ()  bug above
also have caused that divergent compile?  I guess it depends on what
SML/NJ does with open temporary files, but that seems unlikely.