Closed Bug 677019 Opened 9 years ago Closed 8 years ago
TI: Different output with/without options "-n -a" and Array
The attached testcase produces different output with option combinations "-j -m" vs. "-j -m -n -a", tested on TI revision 3b40e4462464: $ $JS -j -m main.js f29f27a507e2cba5c41e4489d303b78b209dbf74.js f7b783e07cd0e61b675319866b62c96b521d3c12.js f7b783e07cd0e61b675319866b62c96b521d3c12.js $ $JS -j -m -n -a main.js f29f27a507e2cba5c41e4489d303b78b209dbf74.js f7b783e07cd0e61b675319866b62c96b521d3c12.js 1024
Forgot the testcase -.-
Summary: TI: Different output with/without options "-n -a" → TI: Different output with/without options "-n -a" and Array.prototype
I have a lot more examples with similar behavior, all contain __proto__ or prototype. I assume these are all related and this bug can manifest not only through Array.prototype.
Weird/silly PIC bug. GETPROP and the associated PIC code make a tacit assumption that they are actually at a GETPROP, which I think cannot represent indexed properties. This allows them to use js_GetProtoIfDenseArray after checking for '.length', as dense arrays only have .length and indexed properties. The GETELEM polymorphic IC uses the same mechanism, however, and used the PIC code for an access on the "0" property, which ended up skipping to Array.prototype even though the dense array itself had the property. This bug is also on trunk (manifests only with -n because of different PIC access pattern induced by recompilation). Should be harmless but could still get fixed there. It would also be nice to remove js_GetProtoIfDenseArray entirely I think, I doubt it buys anything with TI. http://hg.mozilla.org/projects/jaegermonkey/rev/0a6ba466113f
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.