> I just tried a new G0 -> G1 native compile and it failed with an assertion
> failure (toX86Blocks: Move) in the native backend. I've made a lot of changes
> to other parts of the compiler, but the only changes I've made to the native
> backend were in x86-translate to add Word{8,32}_neg and the new outputAssembly.
> A snapshot of the sources that produces the failure is available at
> http://www.star-lab.com/sweeks/mlton.tgz. Here is the log.
> x86 code gen starting
> outputC starting
> outputC finished in 1.170
> outputAssembly starting
> translateChunk raised
> outputAssembly raised in 5.670
> x86 code gen raised in 130.760
> compile raised in 2049.230
> mlton: assertion failure: toX86Blocks: Move
I think that corresponds to a type-error in the corresponding
MachineOutput.Statement.Move {src, dst}
expression.
All that assertion does is compare the x86 sizes of src and dst for
equality. The x86 size of a MachineOutput.Operand.t is calculated by a
simple map on it's type. The map (from x86-mlton.fun) looks like:
local
open MachineOutput.Type
in
fun toX86Size t
= case dest t
of Char => x86.Size.BYTE
| Double => x86.Size.DBLE
| Int => x86.Size.LONG
| Pointer => x86.Size.LONG
| Uint => x86.Size.LONG
| Void => x86.Size.VOID
end
My understanding was that a MachineOutput.Statement.Move would always have
source and destination of the same type.
If the C backend produces an executable, then my guess is that somewhere
along the line a coercion function got dropped, which C is adding back.
Otherwise, I'd guess that void creeped in somehow.
(text/plain)