Floats in squeak...
Joshua 'Schwa' Gargus
schwa at cc.gatech.edu
Sat Sep 6 18:52:51 UTC 2003
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.
>
More information about the Squeak-dev
mailing list
|