[Webkit-unassigned] [Bug 18274] New: ResolveNode::emitCode()
doesn't make a new temporary when dst is 0,
leading to incorrect codegen
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Apr 1 19:35:52 PDT 2008
http://bugs.webkit.org/show_bug.cgi?id=18274
Summary: ResolveNode::emitCode() doesn't make a new temporary
when dst is 0, leading to incorrect codegen
Product: WebKit
Version: 526+ (Nightly build)
Platform: Macintosh
OS/Version: Mac OS X 10.5
Status: NEW
Keywords: SquirrelFish
Severity: Normal
Priority: P2
Component: JavaScriptCore
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: cwzwarich at uwaterloo.ca
This JavaScript
var o = { a: function () { return 1; } };
o.a();
o;
generates the following code:
[ 0] load lr1, undefined(@k0)
[ 3] new_object lr1
[ 5] new_func_exp tr0, f0
[ 8] put_prop_id lr1, a(@id0), tr0
[ 12] get_prop_id tr0, lr1, a(@id0)
[ 16] call lr1, tr0, lr1, 8, 1
[ 22] end lr1
The end call ends up overwriting the local variable o with 1, which is clearly
incorrect. Obviously, we don't always want ResolveNode::emitCode() to return a
new temporary register if dst is unspecified. However, there are two situations
where this causes a bug:
1) The returned register is reused. This occurs in FunctionCallDotNode and
FunctionCallBracketNode. I have a patch that fixes this particular problem, and
I will post it for review. DoWhileNode and ForNode increment the reference
count of the returned register, but only to return it, not to reuse it.
2) The returned register is ignored, requiring dst to be the actual target.
This occurs in codegen for IfNode, IfElseNode, WhileNode, and ForInNode. It
doesn't cause any realistic problems in any of them, because they are
statements. The first three return 0 as it is, and ForInNode returns dst, which
still isn't a problem if it doesn't contain the correct value, because nothing
will use it once we have completions working.
Should we just accept this behaviour of emitNode and remember to code around
it?
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list