Comment #1 on issue 1181 by [email protected]: Bug in OSR on ARM
http://code.google.com/p/v8/issues/detail?id=1181
Examining the Raytrace benchmark I could narrow down on the bug.
It may actually not be directly linked to OSR. It just happened that
enabling or disabling OSR made the bug appear / disappear.
Could you please rename the issue to something more meaningful.
## Details:
# JS code:
var canvasHeight = 20;
var canvasWidth = 20;
function test(x, y) {
var xp = x / canvasWidth * 2 - 1;
var yp = y / canvasHeight * 2 - 1;
print(" (" + x + ", " + y + ") -> (" + xp + " , " + yp + ")");
}
for(var y=0; y < canvasHeight; y++){
for(var x=0; x < canvasWidth; x++){
test(x, y);
}
}
# Description
* Expected output: yp should take floating-point values (-1, -0.8, -0.6,
etc).
* Observed output: yp is rounded to an integer.
A conversion from double to integer is wrongly (?) generated for yp.
Observing the generated code (see attached file lines 1538, 1617, 1690)
clearly shows that the operation is correct for xp but not for yp.
Attached file is the the output of:
./shell_g --crankshaft test/local/fp.js --trace_hydrogen --print_code
--code_comments
(revision 6893; r6894 breaks --code_comments on ARM)
# Trigger the bug
To trigger the bug, run the previous JS code with an ARM debug shell
(simulator or hardware) with crankshaft activated.
I observe a high probability of the bug appearing with a debug shell, but
can't see it with a release shell.
Attachments:
fp.arm.comments 104 KB
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
