While working on unit tests for 661425 I included a test for this.

There is no compiler warning but the test does fail.

https://codereview.chromium.org/2469893005/ contains template code for a unit test that would cover this.  Just need to add this test:

    TEST(HashFunctionsTest, Int64IntHashCollisions) {
      auto result = countCollisions<std::pair<uint64_t, unsigned>, 2>(3);
      auto expect = expectedCollisions(result.second);
      auto allowed = static_cast<size_t>(ceil(3.0 * expect));
      EXPECT_LE(result.first, allowed);
    }

and that test will currently fail.

Fixing this could conceivably introduce a performance regression and might not improve real-world collision performance, so it's not clear that anything needs to be done.

Yeah, this sounds like a bug.

I think fixing this (in a correct manner) won't cause a perf regression, because
it is guarded by a template.

Sorry, I've realized I misunderstood the problem after I looked at the CL.

I'm not sure if we should fix this, unless we have some evidence showing that
we have too many collisions caused by this glitch in some real world scenarios.

In our HashTable implementation, we chop off the hash value down to a few bits
(depending on the table size), so the quality of hash values does not really
matter in most cases. According to my prior research (on string hashes rather
than int hashes), I found the calculation speed was much more important than
the hash quality. So, assuming the same applies for int hashes, I guess we can
leave it as it is...

(This is not my area - why did I get cc'ed? Did you intend to cc someone else?)

Oops, my bad (removing from cc).