Fix more -Werror=sign-compare bugs with GCC 4.9.2

Fix more -Werror=sign-compare bugs with GCC 4.9.2

R=svenpanne@chromium.org
LOG=N
BUG=

Committed: https://crrev.com/004bb77ec5ca3a8c6a1a794b6db1807f3730a5d5
Cr-Commit-Position: refs/heads/master@{#28337}

[wingo, 2015-05-11 07:56:18]

What do you want to do with these, Sven?  I can always build locally with
-Werror off, we can change the DCHECK_EQ somehow, or I can continue to submit
these.  As you like, let me know.

[wingo, 2015-05-11 08:31:41]

On 2015/05/11 07:56:18, wingo wrote:
> What do you want to do with these, Sven?  I can always build locally with
> -Werror off, we can change the DCHECK_EQ somehow, or I can continue to submit
> these.  As you like, let me know.

Related link:
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types

I guess other projects using Google's style guide just use signed types for
counters and so don't see this problem.  Seems gross but I guess you can get
used to anything.

[Jakob Kummerow, 2015-05-11 10:29:10]

jkummerow@chromium.org changed reviewers:
+ jkummerow@chromium.org

[Jakob Kummerow, 2015-05-11 10:29:10]

Sven's on vacation. I like these changes (although I'm kinda surprised that your
"homeopathic" clang=0 build keeps running into them :-P ).

LGTM.

[wingo, 2015-05-11 10:35:10]

On 2015/05/11 10:29:10, Jakob wrote:
> Sven's on vacation. I like these changes (although I'm kinda surprised that
your
> "homeopathic" clang=0 build keeps running into them :-P ).
> 
> LGTM.

Tx for the review :)

Regarding my build, I think I was led to believe by
https://code.google.com/p/v8-wiki/wiki/BuildingWithGYP that I could pass gyp
parameters as make parameters ;)  It seems that the necessary invocation is to
set GYP_DEFINES=clang=0, re-run build/gyp_v8, then make.  "Enhance your life via
the mystic powers of crystals^Hbuild tools", or something :)

[wingo, 2015-05-11 10:35:16]

The CQ bit was checked by wingo@igalia.com

[commit-bot: I haz the power, 2015-05-11 10:35:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1128043002/20001

[Jakob Kummerow, 2015-05-11 10:50:08]

On 2015/05/11 10:35:10, wingo wrote:
> Regarding my build, I think I was led to believe by
> https://code.google.com/p/v8-wiki/wiki/BuildingWithGYP that I could pass gyp
> parameters as make parameters ;)

Well, no. There's no magic there. The Makefile defines its own set of flags and
manually translates them to GYP parameters. (In many cases they're identical,
but that's coincidence.)

> It seems that the necessary invocation is to
> set GYP_DEFINES=clang=0, re-run build/gyp_v8, then make.

Almost: you should never need to run build/gyp_v8 when you use the make build.
The Makefile will take care of everything. build/gyp_v8 is for non-make builds.

[commit-bot: I haz the power, 2015-05-11 11:07:17]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-11 11:07:35]

Patchset 2 (id:??) landed as
https://crrev.com/004bb77ec5ca3a8c6a1a794b6db1807f3730a5d5
Cr-Commit-Position: refs/heads/master@{#28337}

[Sven Panne, 2015-05-18 10:53:00]

On 2015/05/11 07:56:18, wingo wrote:
> What do you want to do with these, Sven?  I can always build locally with
> -Werror off, we can change the DCHECK_EQ somehow, or I can continue to submit
> these.  As you like, let me know.

[ Better late than never... ;-) ]

The underlying problem here is the combination of macros, templates, template
specializations and plain functions involved plus C++'s arcane rules for
overload resolution, see
http://en.cppreference.com/w/cpp/language/overload_resolution and admire its
beauty and simplicity, but be sure to read the whole page including the "Best
viable function" section, which is relevant for the warning you encounter. :-D
My personal POV is that the (D)CHECK_EQ macros (and friends) should be avoided
and only plain (D)CHECK should be used, but other people and presubmit.py
disagree. :-P So the rule of thumb should be: Make sure that you don't mix types
in the arguments of (D)CHECK_EQ and friends, and that's exactly what you did.

In a nutshell: LGTM, too.