Fix -Wshift-negative-value transgression in tcmalloc.

third_party/tcmalloc/chromium/src/base/basictypes.h

Index: third_party/tcmalloc/chromium/src/base/basictypes.h
diff --git a/third_party/tcmalloc/chromium/src/base/basictypes.h b/third_party/tcmalloc/chromium/src/base/basictypes.h
index 75b7b5ae777ae06b81ad63aa3912df8b58368aab..5a578fed948b058fd2ac6fd71b724071a5fd6ceb 100644
--- a/third_party/tcmalloc/chromium/src/base/basictypes.h
+++ b/third_party/tcmalloc/chromium/src/base/basictypes.h
@@ -82,7 +82,7 @@ const  int64 kint64max =  ( ((( int64) kint32max) << 32) | kuint32max );
 const  int8  kint8min   = (   (  int8) 0x80);
 const  int16 kint16min  = (   ( int16) 0x8000);
 const  int32 kint32min  = (   ( int32) 0x80000000);
-const  int64 kint64min =  ( ((( int64) kint32min) << 32) | 0 );
+const  int64 kint64min =  (-kint64max - 1LL);

[Primiano Tucci (use gerrit), 2017/04/02 16:49:44]

took my a while to figure out why this was defined like this (which, after some
googling, seems to match most #define INT64_MIN out there).
It's impressive how these days we have very sophisticated features like lambdas
with captures, rvalue references, thread-safe statics, but still, integers are
so frighteningly easy to get wrong.

Instead, I have to admit I still can't figure out the kint64max above ? Why
isn't that just 0x7fff(enough f's)LL ? (and, to be clear, I am not implying we
should change it, but just curious at this point)

[Nico, 2017/04/02 18:17:54]

0xffff is an int literal. 0xffffLL should work, but that wasn't standardized
until I think c++11, and tcmalloc predates that. I agree that would be better,
but the current way fits the file better. (There's a lot of stuff in here we
could delete with c++11.)

[Lei Zhang, 2017/04/03 20:51:07]

Do we want to file a bug to refresh tcmalloc with C++11?

 
 // Define the "portable" printf and scanf macros, if they're not
 // already there (via the inttypes.h we #included above, hopefully).