On Sat, 7 Apr 2001, Raab, Andreas wrote:
> 
> compile.cc: in `void gen_compile()'
> compile.cc:1111: phase error at sPC 26: 0084F18D r.d.. 1<  41 0084F1A8
> LdTemp 1
> 
> (whatever that means ;-)

That means (I'm assuming you can figure out everything up to and including
the third `:' for yourself ;-) :

 phase error
	the address of the translated code for this instruction recorded
        during the first pass of code generation was different to the
	address observed during the second pass

 at sPC 26:
	this is the sam (Squeak Abstract Machine) PC for the offending
	instruction (the insn at which the problem was noticed, not
	necessarily the insn that caused the problem)

 0084F18D
	this is the address of the 26th insn seen during the second
	codegen pass (it's therefore the 25th that caused the problem, by
	having differently-sized code on the second pass -- possibly a
	short/long branch range thing on the 386???)

 r	this insn is a join of two or more control flows
 .	this insn is not preceded by an unconditional control transfer
 d	this insn is the destination of a control transfer
 .	this insn does not have an ambiguous stack depth
 .	this insn is not squashed after being subsumed by a
		"macro" insn preceding it

 1<	one non-linear flow of control arrives at this insn

 41	this is the virtual PC (offset of the corresponding bytecode in
	the original CompiledMethod) of this insn

 0084F1A8
	this is the native PC (translated code address) the insn recorded
	during the codegen first pass

 LdTemp 1
	the sam opcode at which the problem was noticed (not the one
	that caused the problem, but the one after it)

FWIW, 0084F1A8 - 0084F18D = 27 additional bytes compiled for the 25th
insn during the second pass, which seems *huge*.  If you have a copy
of GNU libopcodes then you can define DSM_LISTING in compile.cc, link
against libopcodes.a, and j3 will dump a disassembly listing of the
translated code as it is generated, one sam insn at a time -- which is
often invaluable for tracking down the cause of this kind of problem.

I hope some of that turns out to be of use.

Ian