The plain MinGW enviroment does not provide any threading supporting, including
in the C++ STL. The MinGW-w64 enviroment does not have this problem.

This patch removes the 32 bit bot since it's always going to fail.

See https://github.com/google/benchmark/issues/272

This patch adds the compare_bench.py utility which can be used to compare the result of benchmarks.
The program is invoked like:

$ compare_bench.py <old-benchmark> <new-benchmark> [benchmark options]...
Where <old-benchmark> and <new-benchmark> either specify a benchmark executable file, or a JSON output file. The type of the input file is automatically detected. If a benchmark executable is specified then the benchmark is run to obtain the results. Otherwise the results are simply loaded from the output file.

Currently out Appveyor CI downloads and stashes a custom MinGW installation.
However the builder already provides both 64 and 32 bit installations of MinGW.
This patch changes our CI to use those instead.

I'm hoping this will fix issues where the g++ is broken due to the Appveyor
package caching semantics.

Currently the Appveyor bot is a PIT. It never passes and it often hangs
or gives very poor output. This patch rewrites the configuration.

This patch also attempts to fix a flaky complexity test as a drive-by.

This patch adds three new build configurations to the travis CI.

* Clang 3.8 w/ libc++
* Clang 3.8 w/ libc++, UBSAN, ASAN
* Clang 3.8 w/ libc++, MSAN

This patch adds new builders that test against GCC 6 and Clang 3.8 respectivly.
They also enable both address and undefined sanitizer. MSAN currently won't work
since it requires a sanitized STL.

Previously the FittingCurve functions for n^2 and n^3 did the calculation
using int types. This can overflow and cause UB. This patch changes the
calculations to use std::pow to prevent this.

Also re-enable VC 2013 appveyor bot since I *hope* this is what was causing
the failures.

This is secretly just a test commit to get appveyor to run again.

VC 2013 injects valid when  assigning an initializer list to std::set.
This attempts to work around this issue by using std::set's constructors
instead of the assignment operators.

* Support multiple ranges in the benchmark

google-benchmark library allows to provide up to two ranges to the
benchmark method (range_x and range_y). However, in many cases it's not
sufficient. The patch introduces multi-range features, so user can easily
define multiple ranges by passing a vector of integers, and access values
through the method range(i).

* Remove redundant API

Functions State::range_x() and State::range_y() have been removed. They should
be replaced by State::range(0) and State::range(1).
Functions Benchmark::ArgPair() and Benchmark::RangePair() have been removed.
They should be replaced by Benchmark::Args() and Benchmark::Ranges().

* Add RegisterBenchmark

* fix test inputs

* fix UB caused by unitialized value

* Add RegisterBenchmark

* fix test inputs

* fix UB caused by unitialized value

* Work around GCC 4.6/4.7/4.8 bug

These options allow you to write the output of a benchmark to the specified
file and with the specified format. The goal of this change is to help support
tooling.

GCC 4.6 doesn't provide std::chrono::steady_clock and GCC 4.7 doesn't provide
std::this_thread::sleep_for. I would prefer to support GCC 4.7 but I'm
reverting this since the bots are GCC 4.6.

This reverts commit c5f45495.

GCC 4.7 doesn't provide std::this_thread::sleep_for on my system.
This patch changes the tests to use a different method for wasting
cycles.

Without these, clang reorders these instructions as if they were
regular loads/stores which causes SIGILL from the kernel because
it performs all the loads before it starts testing the values.

This implementation is less likely to ICE compilers, and is more correct.
It also acts as a memory barrier which will help prevent writes to global memory
from being optimized away.

Add policy CMP0056, which honors the link flags in try_compile and
try_run. This allows for building against non-system libc++ by providing
the correct -L and rpath options in a containing project.

For example:

    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L ${LLVM_ROOT}/lib -l c++ -l c++abi")
    set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-rpath,${LLVM_ROOT}/lib")

Add `state.SetComplexityN(state.range_x());` to documentation so that complexity is calculated correctly.