642236 - ECMA spec not followed on comparisons

Status: RESOLVED DUPLICATE of bug 640052

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Virgil Palanciuc]

Ecmascript goes to great lengths to ensure that operands of comparisons are evaluated in-order, introducing even the "LeftFirst" flag in section 11.8.5.
Tamarin, however, doesn't seem to pay attention to the rules. Try this example:
//=======================================
function MyValueAlteringObject(value) {
    this.value = value;
    this.valueOf = function(){ return ++this.value;  };
}

var nvo = new MyValueAlteringObject(1.0);
trace(nvo>nvo); // returns true; should really return false!
//=======================================

The reason is that in implementation, the evaluation order is reversed. E.g. in interpreter:
  INSTR(lessthan) {
       // Ok, core->compare evaluates first ToPrimitive(a1), then ToPrimitive(a2)
       CMP2(<, core->compare(a1,a2) == trueAtom);
       NEXT;
  }

 INSTR(greaterthan){
   // See? no "leftfirst" flag!!!  ToPrimitive(a2) will be evaluated first!!!
     CMP2(>, core->compare(a2, a1) == trueAtom);
     NEXT;
 }



Final note: This applies to JIT as well - because JIT-ed code will call compare() too, in a similar fashion.

Comment 1

[Edwin Smith]

This might be a dupe of: bug 640052

Could you take a look and see if you agree with my conclusion that the JIT and Interpreter agree with either, even though they both get the evaluation order wrong in 1/2 the cases?

Comment 2

[Virgil Palanciuc]

Yes, from what I saw I'm pretty sure your conclusion is correct; unfortunately I *really* have to leave now (and I'll be away for 3 days) - I can only do an in-depth/exhaustive check on Tuesday, earliest.

Comment 3

[Virgil Palanciuc]

I checked, JIT is *mostly* in agreement with interpreter. What I mean is that, strictly speaking, the JIT-ed code may have different evaluation order than the interpreted code - but only when the values being compared are primitives (numbers, strings - i.e., in cmpOptimization ). While strictly-speaking the evaluation order is different than the interpreter, I can't think of a single example where it would make a (visible) difference in the end result.


And I agree, this bug is a dupe of 640052. Will mark as such.