Last Comment Bug 646938 - JM: x === x fails when x is -NaN
: JM: x === x fails when x is -NaN
Status: RESOLVED FIXED
fixed-in-tracemonkey
: regression, reproducible, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Jan de Mooij [:jandem]
:
Mentors:
Depends on:
Blocks: Jaeger
  Show dependency treegraph
 
Reported: 2011-03-31 11:43 PDT by Jan de Mooij [:jandem]
Modified: 2011-04-26 15:31 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (2.61 KB, patch)
2011-04-01 15:43 PDT, Jan de Mooij [:jandem]
dvander: review+
Details | Diff | Splinter Review
Patch (4.60 KB, patch)
2011-04-22 01:50 PDT, Jan de Mooij [:jandem]
dvander: review+
Details | Diff | Splinter Review

Description Jan de Mooij [:jandem] 2011-03-31 11:43:45 PDT
--
function f() {
    var x = -[NaN][0];
    print(x === x);
}
f();
--
With -m -a this prints |true| instead of |false|. 

I think jsop_neg flips the first bit and this fails the check in jsop_stricteq.
Comment 1 Jan de Mooij [:jandem] 2011-04-01 15:43:47 PDT
Created attachment 523710 [details] [diff] [review]
Patch

This patch fixes the NaN-check in stricteq to ignore the sign bit. The alternative is to add a NaN-check to jsop_neg but that seems more expensive than this patch.
Comment 2 Brendan Eich [:brendan] 2011-04-03 17:36:17 PDT
IIRC neg is very rare, eq is quite common. Not sure about stricteq vs. neg but I would not be surprised if stricteq was more frequent, statically and dynamically. dmandelin, any data?

/be
Comment 3 Jan de Mooij [:jandem] 2011-04-04 05:12:21 PDT
(In reply to comment #2)
> IIRC neg is very rare, eq is quite common. Not sure about stricteq vs. neg but
> I would not be surprised if stricteq was more frequent, statically and
> dynamically.

This is about the stricteq case where lhs and rhs have the same backing (same local or copy of same local). Thinking about this more, I should probably fix jsop_neg first and benchmark.
Comment 4 Jan de Mooij [:jandem] 2011-04-04 06:18:47 PDT
Comment on attachment 523710 [details] [diff] [review]
Patch

OK this is interesting. GCC implements -(double) like JM does (xor with sign mask). This means that fixing jsop_neg is not enough as we can still get a -NaN from the interpreter.
Comment 5 David Mandelin [:dmandelin] 2011-04-06 11:30:20 PDT
(In reply to comment #2)
> IIRC neg is very rare, eq is quite common. Not sure about stricteq vs. neg but
> I would not be surprised if stricteq was more frequent, statically and
> dynamically. dmandelin, any data?

In the V8 benchmarks, neg is rare, and eq/stricteq are common. In SunSpider (which we care less about than we used to), stricteq is rare; eq and neg are both fairly common, but eq runs 2x as many times as neg.
Comment 6 David Anderson [:dvander] 2011-04-15 18:35:08 PDT
Comment on attachment 523710 [details] [diff] [review]
Patch

bonus points if you change that r11 to scratchRegister ;)
Comment 7 Jan de Mooij [:jandem] 2011-04-22 01:50:27 PDT
Created attachment 527741 [details] [diff] [review]
Patch

scratchRegister was protected, this patch makes it public like stackPointerRegister.
Comment 8 Jan de Mooij [:jandem] 2011-04-26 01:37:24 PDT
http://hg.mozilla.org/tracemonkey/rev/de7b0f3323c1
Comment 9 Chris Leary [:cdleary] (not checking bugmail) 2011-04-26 15:31:24 PDT
http://hg.mozilla.org/mozilla-central/rev/de7b0f3323c1

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