Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 658240 - TI+JM: incorrect result with +=, parseFloat
: TI+JM: incorrect result with +=, parseFloat
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: infer-regress
  Show dependency treegraph
Reported: 2011-05-19 06:18 PDT by Jan de Mooij [:jandem]
Modified: 2011-05-19 16:05 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Jan de Mooij [:jandem] 2011-05-19 06:18:49 PDT
This test is reduced from the Mochitest-2 orange.
function f() {
    var x = 0;
    for(var i=0; i<5; i++) {
        (function() {
            x += parseFloat("2");
    return x;
assertEq(f(), 10);
$ ./js -m -n -a test.js
test.js:10: Error: Assertion failed: got 2, expected 10

parseFloat has TypeHandlerFloat and returns an int32 value. Similar functions like (2).valueOf() also fail.
Comment 1 Brian Hackett (:bhackett) 2011-05-19 16:05:19 PDT
It's OK for natives to return ints when their handler is a float, we'll convert it to a float when merging back into the inline path.  The problem here was that when generating a PIC for the GETXPROP used in the '+=' we did not update the possible types pushed by the PIC, as we do for GETPROP and NAME ICs (grumble...)

Note You need to log in before you can comment on or make changes to this bug.