Pádraig Brady <[email protected]> writes: > This is useful to give better test coverage at least, > and may be useful for users who already may have > GLIBC_TUNABLES defined to tune their environment, > avoiding CPU throttling for example. > > * src/cpu-supports.h: A new header that provides cpu_supports() > that checks the GLIBC_TUNABLES environment variable allows > the hardware feature, before checking with __builtin_cpu_supports(). > * src/cksum.c: Use cpu_supports() rather than __builtin_cpu_supports(). > * src/wc.c: Likewise. > * src/local.mk: Reference the new header. > * tests/cksum/cksum.sh: Adjust to testing all implementations. > * tests/wc/wc-cpu.sh: A new test to do likewise. > * tests/local.mk: Reference the new wc test. > --- > src/cksum.c | 25 ++++++++------ > src/cpu-supports.h | 78 ++++++++++++++++++++++++++++++++++++++++++++ > src/local.mk | 1 + > src/wc.c | 3 +- > tests/cksum/cksum.sh | 23 +++++++++---- > tests/local.mk | 1 + > tests/wc/wc-cpu.sh | 34 +++++++++++++++++++ > 7 files changed, 148 insertions(+), 17 deletions(-) > create mode 100644 src/cpu-supports.h > create mode 100755 tests/wc/wc-cpu.sh
Probably worth documenting this behavior. Although it is hard to imagine that many people use the glibc.cpu tunables to disable capabilities that their hardware supports, one might be surprised that Coreutils checks them unless it is documented. Also, worth mentioning that the OpenSSL implementations of digests won't respect this. Collin
