Bug 95418 - Build warning : -Wsign-compare on DFGByteCodeParser.cpp.
Summary: Build warning : -Wsign-compare on DFGByteCodeParser.cpp.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-29 20:05 PDT by Byungwoo Lee
Modified: 2012-08-30 11:44 PDT (History)
3 users (show)

See Also:


Attachments
Patch (3.08 KB, patch)
2012-08-29 20:28 PDT, Byungwoo Lee
no flags Details | Formatted Diff | Diff
Patch (2.23 KB, patch)
2012-08-29 23:35 PDT, Byungwoo Lee
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Byungwoo Lee 2012-08-29 20:05:38 PDT
There is a build warning '-Wsign-compare' on findArgumentPositionForLocal() function in DFGByteCodeParser.cpp
Comment 1 Byungwoo Lee 2012-08-29 20:28:22 PDT
Created attachment 161393 [details]
Patch
Comment 2 Kentaro Hara 2012-08-29 20:37:09 PDT
Comment on attachment 161393 [details]
Patch

OK
Comment 3 Build Bot 2012-08-29 20:45:16 PDT
Comment on attachment 161393 [details]
Patch

Attachment 161393 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/13681523
Comment 4 Filip Pizlo 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.
Comment 5 Byungwoo Lee 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 :)
Comment 6 Filip Pizlo 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.
Comment 7 Byungwoo Lee 2012-08-29 23:35:41 PDT
Created attachment 161408 [details]
Patch
Comment 8 Filip Pizlo 2012-08-29 23:39:00 PDT
Comment on attachment 161408 [details]
Patch

This looks good.  Hopefully it will pass all the bots!
Comment 9 Byungwoo Lee 2012-08-30 09:43:11 PDT
All the bots were passed. Thanks for your reviews. :)
Comment 10 WebKit Review Bot 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>
Comment 11 WebKit Review Bot 2012-08-30 11:44:42 PDT
All reviewed patches have been landed.  Closing bug.