* Extend perf counter support to multi-threaded cases.

* Docs update

* const-ed Snapshot

* Support -Wsuggest-override

google/benchmark is C++11 compatible but doesn't use the `override` keyword.
Projects using google/benchmark with enabled `-Wsuggest-override` and `-Werror` will fail to compile.

* Add -Wsuggest-override cxx flag

* Revert unrelated formatting

* Revert unrelated formatting, take 2

* Revert unrelated formatting, take 3

* Disable -Wsuggest-override when compiling tests, gtest does not handle it yet
Co-authored-by: Dominic Hamon <dominichamon@users.noreply.github.com>

* Refactor BenchmarkInstance (precursor to #1105)

* fix bazel (debug) build

* clang-format on header

* fix build error on g++-4.8

* add g++-6 to ubuntu-14.04

* fix syntax

* fix yamllint errors for build-and-test

* fix 'add-apt-repository' command not found

* make 'run tests' explicit

* enable testing and run both release and debug

* oops

* Add ubuntu-14.04 build and test workflow

* avoid '.' in job name

* no need for fail fast

* fix workflow syntax

* install some stuff

* better compiler installations

* update before install

* just say yes

* trying to match up some paths

* Difference between runner and github context in container?

* Try some judicious logging

* cmake 3.5+ required

* specific compiler versions

* need git for googletest

* Disable testing on old compilers

* disable testing properly

This also fixes #1135. Because StrSplit was returning a vector with an
empty string, it was treated by PerfCounters::Create as a legitimate ask
for setting up a counter with that name. The empty vector is understood
by PerfCounters as "just return NoCounters()".

* Add API to benchmark allowing for custom context to be added

Fixes #525

* add docs

* Add context flag output to JSON reporter

* Plumb everything into the global context.

* Add googletests for custom context

* update docs with duplicate key behaviour

* Add `benchmark_context` flag that allows per-run custom context.

Add support for key-value flags in general.
Added test for key-value flags.
Added `benchmark_context` flag.
Output content of `benchmark_context` to base reporter.

Solves the first part of #525.

* Docs and better help

* Add 32-bit build support to build-and-test

* attempt different yaml multiline string format

* syntax fixes to yaml

* switch to getting alternative compilers working

* remove done TODO

* trying to separate out windows

* oops, typo.

* add TODOs for missing builds wrt travis

* Support optional, user-directed collection of performance counters

The patch allows an engineer wishing to drill into the root causes
of a regression, for example. Currently, only single threaded runs
are supported. The feature is a build-time opt in, and then a runtime
opt in.

The engineer may run the benchmark executable, passing a list of
performance counter names (using libpfm's naming scheme) at the
command line. The counter values will then be collected and reported
back as UserCounters.

This is different from #240 in that it is a benchmark user opt-in, and
the counter collection is transparent to the benchmark.

Currently, this is only supported on platforms where libpfm is
supported.

libpfm: http://perfmon2.sourceforge.net/

* 'Use' values param in Snapshot when BENCHMARK_OS_WINDOWS

This is to avoid unused parameter warning-as-error

* Added missing include for <vector> in perf_counters.cc

* Moved doc to docs

* Added license blurbs

Fixes #713

according to https://cmake.org/cmake/help/latest/command/function.html,
"Referencing to ARGV# arguments beyond ARGC have undefined behavior.",
which I hit with cmake 3.19.7.

This uses ARGC to check whether ARGV1 has been passed before referencing
it.

[tools] Fix dumb mistake in previous commit - print aggregates only means aggregates, not non-aggregates

This probably regressed in #1042.

Currently, i get:
```
Run on (32 X 7326.56 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x16)
  L1 Instruction 32 KiB (x16)
  L2 Unified 512 KiB (x16)
  L3 Unified 32768 KiB (x2)
```
which seems mostly right, except that the frequency is rather bogus.
Yes, i guess the CPU could theoretically achieve that,
but i have 3.6GHz configured, and scaling disabled.
So we clearly read the wrong thing.

With this fix, i now get the expected
```
Run on (32 X 3598.53 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x16)
  L1 Instruction 32 KiB (x16)
  L2 Unified 512 KiB (x16)
  L3 Unified 32768 KiB (x2)
```

Use the benchmark's reported iteration count when estimating
iterations for the next repetition, rather than the requested
iteration count.  When the benchmark uses KeepRunningBatch the actual
iteration count can be larger than the one the runner requested.

Prior to this fix the runner was underestimating the next iteration
count, sometimes significantly so.  Consider the case of a benchmark
using a batch size of 1024.  Prior to this change, the benchmark
runner would attempt iteration counts 1, 10, 100 and 1000, yet the
benchmark itself would do the same amount of work each time: a single
batch of 1024 iterations.  The discrepancy could also contribute to
estimation errors once the benchmark time reached 10% of the target.
For example, if the very first batch of 1024 iterations reached 10% of
benchmark_min_min time, the runner would attempt to scale that to 100%
from a basis of one iteration rather than 1024.

This bug was particularly noticeable in benchmarks with large batch
sizes, especially when the benchmark also had slow set up or tear down
phases.

With this fix in place it is possible to use KeepRunningBatch to
achieve a kind of "minimum iteration count" feature by using a larger
fixed batch size.  For example, a benchmark may build a map of 500K
elements and test a "find" operation.  There is no point in running
"find" just 1, 10, 100, etc., times.  The benchmark can now pick a
batch size of something like 10K, and the runner will arrive at the
final max iteration count with in noticeably fewer repetitions.

* See if bazel "just works" now (almost)

* Add cache and better bazel test command line

* Narrow focus of bazel build

Take advantage of C++17's `[[maybe_unused]]` if it's available. Also clang supports `__attribute__((unused))` so add that too.

When building with gcc TSan on, and in Debug mode, we see a warning
like:

benchmark/src/timers.cc: In function ‘std::string benchmark::LocalDateTimeString()’:
src/timers.cc:241:15: warning: ‘char* strncat(char*, const char*, size_t)’ output may be truncated copying 108 bytes from a string of length 127 [-Wstringop-truncation]
  241 |   std::strncat(storage, tz_offset, sizeof(storage) - timestamp_len - 1);
      |   ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

While this is essentially a false positive (we never expect
the number of bytes in tz_offset to be too large), the compiler can't
actually tell that.  Shrink the size of tz_offset to a smaller, but still safe
size to eliminate this warning.
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>

* Implement custom benchmark name

The benchmark's name can be changed using the Name() function
which internally uses SetName().

* Update AUTHORS and CONTRIBUTORS

* Describe new feature in README

* Move new name function up

Fixes #1106

* Removing conanfile (and support) per #1088

Unclear why this is failing so disabling for now. bazel build still works locally so this is a bazelisk/github workflow thing.

Signed-off-by: SSE4 <tomskside@gmail.com>

Lacks CMake support, see https://github.com/google/benchmark/pull/1090