- 23 Oct, 2019 2 commits
-
-
Kyle Edwards authored
When building on Windows with `BUILD_SHARED_LIBS=ON`, the symbols were not being properly exported in the DLL. Fix this by setting `CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS`. Fixes #888
-
Martin Blanchard authored
Initialize option flags from environment variables values if they are defined, eg. `BENCHMARK_OUT=<filename>` for `--benchmark_out=<filename>`. Command line flag value always prevails. Fixes https://github.com/google/benchmark/issues/881.
-
- 08 Oct, 2019 1 commit
-
-
Paul Wankadia authored
While I'm here, format all of the files that I touched.
-
- 04 Oct, 2019 1 commit
-
-
Kyle Edwards authored
When cross-compiling, this variable was not set on the second run of CMake, resulting in the next check failing even though it shouldn't be run in the first place. Fix this by caching the variable.
-
- 27 Sep, 2019 1 commit
-
-
Chunsheng Pei authored
* fixed the param order in g++ command and fixed the path for -L * reorder the parameters for g++ command
-
- 23 Sep, 2019 2 commits
-
-
Geoffrey Martin-Noble authored
This macro is sometimes already defined and redefining it results in build errors.
-
Geoffrey Martin-Noble authored
These OS's don't always have HOST_NAME_MAX defined, resulting in build errors. A few related changes as well: * Only define HOST_NAME_MAX if it's not already defined. There are some cases where this is already defined, e.g. with NaCl if __USE_POSIX is set. To avoid all of these, only define it if it's not already defined. * Default HOST_NAME_MAX to 64 and issue a #warning. Having the wrong max length is pretty harmless. The name just ends up getting truncated and this is only for printing debug info. Because we're constructing a std::string from a char[] (so defined length), we don't need to worry about gethostname's undefined behavior for whether the truncation is null-terminated when the hostname doesn't fit in HOST_NAME_MAX. Of course, this doesn't help people who have -Werror set, since they'll still get a warning.
-
- 21 Sep, 2019 1 commit
-
-
Colin Braley authored
* Fix missing paren in README code sample, and fix code spacing. * Add Colin Braley to AUTHORS and CONTRIBUTORS.
-
- 20 Sep, 2019 1 commit
-
-
Geoffrey Martin-Noble authored
* Guard ASSERT_THROWS checks with BENCHMARK_HAS_NO_EXCEPTIONS This allows the test be run with exceptions turned off * Add myself to CONTRIBUTORS I don't need to be added to AUTHORS, as I am a Google employee
-
- 16 Sep, 2019 1 commit
-
-
sharpe5 authored
* Update with instructions to build under Visual Studio Fixes Issue #634. I spent 3 days trying to build this library under Visual Studio 2017, only to discover on has to link to `Shlwapi.lib`. Became so frustrated with the docs that I added full build instructions for Visual Studio 2015, 2017 and Intel Comiler 2015 and 2019. * Update headings
-
- 15 Sep, 2019 1 commit
-
-
Attila M. Szilagyi authored
In `cmake/GoogleTest.cmake`, GOOGLETEST_PATH is default-initialized, but that init forgot to account for the fact that the patch is explicitly supposed to be user-configurable. By passing `CACHE` to `set()` we avoid that error.
-
- 21 Aug, 2019 4 commits
-
-
Sayan Bhattacharjee authored
- Adresses : #856 - The unused `doc` argument was removed from the `DEFINE_` macros in `commandlineflags.h` - Converted all the previous `doc` strings passed to the `DEFINE_` macros to multiline comments. -
Sayan Bhattacharjee authored
- Addresses : #858 - Rule `*.swp` is added to `.gitignore` to ensure that the vim temporary `.swp` backup files are ignored and they don't pollute the results of `git status -u`. -
Sayan Bhattacharjee authored
Documentation of basic use of `DenseRange` was added to README.md.
-
Roman Lebedev authored
VS2013 is unsupported since https://github.com/google/benchmark/pull/691 / https://github.com/google/benchmark/commit/eb8cbec0776455463274ea9947ab0ecfe0f768fe but i forgot to update docs. References: * https://github.com/google/benchmark/issues/689 * https://github.com/google/benchmark/pull/691 * https://github.com/google/googletest/pull/1815 * https://github.com/google/benchmark/issues/853 * https://github.com/google/benchmark/pull/854
-
- 12 Aug, 2019 1 commit
-
-
Roman Lebedev authored
While current counters can e.g. answer the question "how many items is processed per second", it is impossible to get it to tell "how many seconds it takes to process a single item". The solution is to add a yet another modifier `kInvert`, that is *always* considered last, which simply inverts the answer. Fixes #781, #830, #848.
-
- 07 Aug, 2019 1 commit
-
-
Eric Fiselier authored
The CSVReporter is deprecated, but we still need to reference it in a few places. To avoid breaking the build when warnings are errors, we need to disable the warning when we do so.
-
- 06 Aug, 2019 1 commit
-
-
LesnyRumcajs authored
* Corrected the installation procedure Now it can be put into a script. * Updated the file tree Necessary after installation instruction change
-
- 30 Jul, 2019 1 commit
-
-
Xinye Tao authored
-
- 29 Jul, 2019 2 commits
-
-
blackliner authored
* corrected cmake commands * Update README.md
-
Boris Dergachov authored
-
- 27 Jul, 2019 1 commit
-
-
Eric Backus authored
* Update AUTHORS and CONTRIBUTORS * Fix WSL self-test failures Some of the benchmark self-tests expect and check for a particular output format from the benchmark library. The numerical values must not be infinity or not-a-number, or the test will report an error. Some of the values are computed bytes-per-second or items-per-second values, so these require that the measured CPU time for the test to be non-zero. But the loop that is being measured was empty, so the measured CPU time for the loop was extremely small. On systems like Windows Subsystem for Linux (WSL) the timer doesn't have enough resolution to measure this, so the measured CPU time was zero. This fix just makes sure that these tests have something within the timing loop, so that the benchmark library will not decide that the loop takes zero CPU time. This makes these tests more robust, and in particular makes them pass on WSL.
-
- 22 Jul, 2019 1 commit
-
-
Roman Lebedev authored
The filenames are consistently inconsistent in windows world, might have something to do with default file system being case-insensitive. While the native MinGW buils were fixed in 52613079 that only addressed the headers, but not libraries. The problem remains when one tries to do a MinGW cross-build from case-sensitive filesystem.
-
- 17 Jul, 2019 1 commit
-
-
Jason Cooke authored
-
- 05 Jul, 2019 1 commit
-
-
Sam Elliott authored
The RISC-V implementation of `cycleclock::Now` uses the user-space `rdcycle` instruction to query how many cycles have happened since the core started. The only complexity here is on 32-bit RISC-V, where `rdcycle` can only read the lower 32 bits of the 64-bit hardware counter. In this case, `rdcycleh` reads the higher 32 bits of the counter. We match the powerpc implementation to detect and correct for overflow in the high bits.
-
- 26 Jun, 2019 1 commit
-
-
Orgad Shaneh authored
and ThreadManager ctor explicit. Reported by CppCheck.
-
- 13 May, 2019 2 commits
-
-
Roman Lebedev authored
Found in -UNDEBUG build
-
Roman Lebedev authored
This is a shameless rip-off of https://github.com/google/benchmark/pull/646 I did promise to look into why that proposed PR was producing so much worse assembly, and so i finally did. The reason is - that diff changes `size_t` (unsigned) to `int64_t` (signed). There is this nice little `assert`: https://github.com/google/benchmark/blob/7a1c37028359ca9d386d719a6ad527743cf1b753/include/benchmark/benchmark.h#L744 It ensures that we didn't magically decide to advance our iterator when we should have finished benchmarking. When `cached_` was unsigned, the `assert` was `cached_ UGT 0`. But we only ever get to that `assert` if `cached_ NE 0`, and naturally if `cached_` is not `0`, then it is bigger than `0`, so the `assert` is tautological, and gets folded away. But now that `cached_` became signed, the assert became `cached_ SGT 0`. And we still only know that `cached_ NE 0`, so the assert can't be optimized out, or at least it doesn't currently. Regardless of whether or not that is a bug in itself, that particular diff would have regressed the normal 64-bit systems, by halving the maximal iteration space (since we go from unsigned counter to signed one, of the same bit-width), which seems like a bug. And just so it happens, fixing *this* bug, fixes the other bug. This produces fully (bit-by-bit) identical state_assembly_test.s The filecheck change is actually needed regardless of this patch, else this test does not pass for me even without this diff.
-
- 11 May, 2019 1 commit
-
-
Roman Lebedev authored
This may or may not have gotten broken now that benchmark was marked as CXX-only.
-
- 10 May, 2019 1 commit
-
-
Michał Janiszewski authored
This will make CMake skip all the checks for C compiler.
-
- 09 May, 2019 1 commit
-
-
Michał Janiszewski authored
Android doesn't support `getloadavg`
-
- 07 May, 2019 1 commit
-
-
Roman Lebedev authored
Weird, but seems consistent with the rest of cmake here.
-
- 01 May, 2019 3 commits
-
-
Shuo Chen authored
This allows a project to include both googletest and benchmark as top-level git submodule. This allows incorporating Benchmark to an existing CMake project that already incorporates googletest. https://github.com/google/googletest/blob/master/googletest/README.md#incorporating-into-an-existing-cmake-project https://github.com/abseil/abseil-cpp/tree/master/CMake#incorporating-abseil-into-a-cmake-project
-
Lockywolf authored
* Add support for GNU Install Dirs from GNU Coding Standards * src/CMakeLists.txt: Added support for setting the standard variables, such as CMAKE_INSTALL_BINDIR. * Replace install destinations by the ones from GNU Coding Standards. * Set the default .cmake and .pc default path. -
Dominic Hamon authored
-
- 30 Apr, 2019 4 commits
-
-
Roman Lebedev authored
Very interesting, i was completely not expecting to see that cmake failure from https://github.com/google/benchmark/pull/801 *here*. This reverts commit 7da47d03.
-
Roman Lebedev authored
Generally we can't just add -m32 in the middle of the build. It currently just happens to work, but that is not guaranteed.
-
Roman Lebedev authored
It was looking in `"<...>/googlebenchmark/build/third_party/googletest"`, with these extra `"` quotes, and wasn't finding anything..
-
Roman Lebedev authored
https://github.com/google/benchmark/pull/801 is stuck with some cryptic cmake failure due to some linking issue between googletest and threading libraries. I suspect that is mostly happening because of the, uhm, intentionally extremely twisted-in-the-brains approach that is being used to actually build the library as part of the buiild, except without actually building it as part of the build. If we do actually build it as part of the build, then all the transitive dependencies should magically be in order, and maybe everything will just work. This new version of cmake magic was written by me in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake.in https://github.com/darktable-org/rawspeed/blob/0e22f085c57cd629983c7351c598abd744b421b5/cmake/Modules/GoogleTest.cmake, based on the official googletest docs and LOTS of experimentation.
-
- 25 Apr, 2019 1 commit
-
-
astee authored
* Update and organize README * Update AUTHORS and CONTRIBUTORS Fixes #803.
-