Bug 95418

Summary: Build warning : -Wsign-compare on DFGByteCodeParser.cpp.
Product: WebKit Reporter: Byungwoo Lee <bw80.lee>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: fpizlo, haraken, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Byungwoo Lee
Reported 2012-08-29 20:05:38 PDT
There is a build warning '-Wsign-compare' on findArgumentPositionForLocal() function in DFGByteCodeParser.cpp
Attachments
Patch (3.08 KB, patch)
2012-08-29 20:28 PDT, Byungwoo Lee
no flags
Patch (2.23 KB, patch)
2012-08-29 23:35 PDT, Byungwoo Lee
no flags
Byungwoo Lee
Comment 1 2012-08-29 20:28:22 PDT
Kentaro Hara
Comment 2 2012-08-29 20:37:09 PDT
Comment on attachment 161393 [details] Patch OK
Build Bot
Comment 3 2012-08-29 20:45:16 PDT
Filip Pizlo
Comment 4 2012-08-29 22:47:53 PDT
Comment on attachment 161393 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=161393&action=review I think what you're hitting here is that different compilers have different opinions about what the sign of arithmetic on a part signed, part unsigned expression is. On our build system, the current setup works - these comparisons are all signed versus signed. If your build system disagrees (which it apparently is doing), you should insert casts into the arithmetic (inlineCallFrame->stackOffset + CallFrame::thisArgumentOffset(), and inlineCallFrame->stackOffset - RegisterFile::CallFrameHeaderSize - inlineCallFrame->arguments.size()) to ensure that it stays signed all the way through. And please don't change operand variables to unsigned. Operands are always signed, since negative operand values carry special meaning. > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:362 > - ArgumentPosition* findArgumentPositionForLocal(int operand) > + ArgumentPosition* findArgumentPositionForLocal(unsigned operand) This is wrong. Operands are always signed integers. > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:370 > - if (operand == inlineCallFrame->stackOffset + CallFrame::thisArgumentOffset()) > + if (static_cast<int>(operand) == inlineCallFrame->stackOffset + CallFrame::thisArgumentOffset()) Change the right hand side of this to static_cast<int>(inlineCallFrame->...) > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:372 > - if (static_cast<unsigned>(operand) < inlineCallFrame->stackOffset - RegisterFile::CallFrameHeaderSize - inlineCallFrame->arguments.size()) > + if (operand < inlineCallFrame->stackOffset - RegisterFile::CallFrameHeaderSize - inlineCallFrame->arguments.size()) Same as above. Change the right hand side to a cast to int. > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:374 > - int argument = operandToArgument(operand - inlineCallFrame->stackOffset); > + int argument = operandToArgument(static_cast<int>(operand) - inlineCallFrame->stackOffset); Remove this.
Byungwoo Lee
Comment 5 2012-08-29 23:20:52 PDT
Comment on attachment 161393 [details] Patch Thanks for your comments to arrange this. I just changed the type of parameter because that, current implementation looks not having the case that a negative value is passed through that parameter. But now I understand your point about the special meaning of the type of the 'operand'. I'll remain the parameter type and make new patch according to your guide. Thanks :)
Filip Pizlo
Comment 6 2012-08-29 23:22:59 PDT
(In reply to comment #5) > (From update of attachment 161393 [details]) > Thanks for your comments to arrange this. > I just changed the type of parameter because that, current implementation looks not having the case that a negative value is passed through that parameter. You are absolutely correct. I just think it's better to maintain consistency here. > But now I understand your point about the special meaning of the type of the 'operand'. > I'll remain the parameter type and make new patch according to your guide. > Thanks :) Cool! Thanks for fixing these issues.
Byungwoo Lee
Comment 7 2012-08-29 23:35:41 PDT
Filip Pizlo
Comment 8 2012-08-29 23:39:00 PDT
Comment on attachment 161408 [details] Patch This looks good. Hopefully it will pass all the bots!
Byungwoo Lee
Comment 9 2012-08-30 09:43:11 PDT
All the bots were passed. Thanks for your reviews. :)
WebKit Review Bot
Comment 10 2012-08-30 11:44:39 PDT
Comment on attachment 161408 [details] Patch Clearing flags on attachment: 161408 Committed r127167: <http://trac.webkit.org/changeset/127167>
WebKit Review Bot
Comment 11 2012-08-30 11:44:42 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.