The following test asserts on mozilla-central revision 4de07a341aab (options -m -n -a):
If I had to guess, I'm betting this has to do with the JSOP_QNAMEPART fugliness for property accesses for __proto__. h8
This has not been fixed on m-c changeset 7c7d2a8db7ff (which has bug 716713 included)
autoBisect shows this is probably related to the following changeset:
The first bad revision is:
user: Brian Hackett
date: Mon Jan 09 06:29:50 2012 -0800
summary: Backout 54cd89b0f1fa (bug 712714 backout). Talos will probably report fake regressions for this patch, do not back out for this reason.
Created attachment 587907 [details] [diff] [review]
Yeah, it's the __proto__ special casing. This bug removes that stuff entirely. It seems only necessary so that the interpreter does not have to check for __proto__ when doing GetProtoIfDenseArray. Interpreter optimizations are no longer necessary/justifiable, and while PICs should still be able to do this stuff they can test for __proto__ before generating code.
(In reply to Brian Hackett (:bhackett) from comment #3)
> Interpreter optimizations are no longer necessary/justifiable
Overstated this a bit. Having significant complexity to occasionally save a few cycles while interpreting is not good.
Comment on attachment 587907 [details] [diff] [review]
Review of attachment 587907 [details] [diff] [review]:
And there was much rejoicing.
Backed out for not building on any platforms except the ones I tested on.
*** Bug 722592 has been marked as a duplicate of this bug. ***
Created attachment 598057 [details] [diff] [review]
Unfortunately the QNAMEPART stuff is also necessary for correct behavior of __proto__ on primitives (which should get e.g. Number.prototype instead of Object.prototype) and there doesn't seem to be an easy/efficient way to fix this. So here's a patch which weakens the assert so that the goofy SWAP; SWAP sequence of bytecodes emitted here is passed through.
Automatically extracted testcase for this bug was committed: