Building with gcc-3.2 fixed the problem.  Thanks.

What should a bug-report to gcc-bugs look like?  Should I include the
incorrect assembly code?  Should I create a minimal program that
exhibits this behavior?  I'm not completely sure how to go about doing
the former, and don't know if the latter is feasible.  Or should I just
describe the symptom?

Thanks,
Joshua

On Sat, Sep 06, 2003 at 07:04:30AM +0200, Ian Piumarta wrote:
> On Fri, 5 Sep 2003, Joshua 'Schwa' Gargus wrote:
> 
> > Did you ever resolve this issue?
> > I haven't gotten too far with debugging this.
> 
> I just tried with the latest Debian compiler on 386.
> 
> The problem is in the interpreter, not in the plugin.  And it looks like a
> compiler bug.
> 
> double stackFloatValue(int offset) is the culprit.  Inserting
> 
> 	printf("result == %lf\n", result);
> 
> just before the return causes it to start working (so it's definitely a
> compiler problem).  Declaring result as static causes the function to
> return the value fetched from the Float on the previous call (i.e., the
> result is out of sync by 1 function call).  Conclusion: fetchFloatAtinto()
> is working but the compiler is loading the double return value from result
> before actually doing the fetch.
> 
> You should switch to a different compiler until it's fixed (and file a
> report to gcc-bugs, if you'd like it to be fixed any time soon ;).
> 
> If that's not an option then one possible expedient hack is to insert an
> empty asm statement [*] before the return from stackFloatValue() like this
> 
> 	fetchFloatAtinto(floatPointer + BaseHeaderSize, result);
> 	asm("");
> 	return result;
> 
> and recompile your VM.  (But there is no telling how many other float
> functions are similarly afflicted, so I don't recommend this as a
> solution.)
> 
> Ian
> 
> [*] This works because the insn scheduler will not move loads across a
> basic block boundary, and it considers any asm() statement -- even an
> empty one -- to be a boundary.
>