Full build precommit bots were failing due to mis-alignment of atomics
in hermetic tests. This PR enforces the alignment for the bump allocator
of hermetic test framework.
Fixes https://github.com/llvm/llvm-project/issues/128185.
Use the trick from gtest to allow `ASSERT_...` and `EXPECT_...`
macros to be used in braceless `if` without producing warnings
about the nested `if`-`else` that results.
Use a combination of polynomial approximation and Newton-Raphson
iterations in 64-bit and 128-bit integers to improve the performance of
sqrtf128. The correct rounding is provided by squaring the result and
comparing it with the argument.
Performance improvement using the newly added perf test:
- My function = the improved implementation from this PR
- Other function = current implementation using
`libc/src/__support/FPUtil/generic/sqrt.h`
```
Performance tests with inputs in denormal range:
-- My function --
Total time : 1260765265 ns
Average runtime : 125.951 ns/op
Ops per second : 7939623 op/s
-- Other function --
Total time : 7160726518 ns
Average runtime : 715.357 ns/op
Ops per second : 1397902 op/s
-- Average runtime ratio --
Mine / Other's : 0.176067
Performance tests with inputs in normal range:
-- My function --
Total time : 373003808 ns
Average runtime : 37.2631 ns/op
Ops per second : 26836189 op/s
-- Other function --
Total time : 7353398916 ns
Average runtime : 734.605 ns/op
Ops per second : 1361275 op/s
-- Average runtime ratio --
Mine / Other's : 0.0507254
```
---------
Co-authored-by: Alexei Sibidanov <sibid@uvic.ca>
`man 3 signal`'s declaration has a face _only a mother could love_.
sighandler_t and __sighandler_t are not defined in the C standard, or POSIX.
They are helpful typedefs provided by glibc and the Linux kernel UAPI headers
respectively since working with function pointers' syntax can be painful. But
we should not rely on them; in C++ we have `auto*` and `using` statements.
Remove the proxy header, and only include a typedef for sighandler_t when
targeting Linux, for compatibility with glibc.
Fixes: #125598
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
These make cross compiling the test suite more difficult, as you need
the
sysroot to contain these headers and libraries cross compiled for your
target.
It's straightforward to stick with the corresponding C headers.
The previous implementation of the ctype functions assumed ASCII.
This patch changes to a switch/case implementation that looks odd, but
actually is easier for the compiler to understand and optimize.
`long double` is haunted on most architectures, but it is especially so on
i386-linux-gnu. While have 80b of significant data, on i386-linux-gnu this type
has 96b of storage.
Fixes for supporting printf family of conversions for `long double` on
i386-linux-gnu. This allows the libc-stdlib-tests and libc_stdio_unittests
ninja target tests to pass on i386-linux-gnu.
Fixes: #110894
Link: #93709
Co-authored-by: Michael Jones <michaelrj@google.com>
`strrchr("foo", '\0')` is defined to point to the end of `foo`, rather
than returning NULL. This wasn't caught by tests, since llvm-libc's
`ASSERT_STREQ(nullptr, "");` is not an assertion error.
While I'm here, refactor the test slightly to check for NULL more
specifically. I considered adding fancier `ASSERT`s (and changing the
semantics of `ASSERT_STREQ`), but opted for a more local fix by fair
dice roll.
Don't use plain `if` for things that are compile-time constants.
Instead, use `if constexpr`. This both ensures that these are
properly wired up constant expressions as intended, and prevents
warnings from the compiler about useless `if` checks that look in
the source like they're meant to do something at runtime but will
just be compiled away.
Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.
Summary:
According to the C++ standard, The main function shall not be declared
with a linkage-specification. after some changes in
https://github.com/llvm/llvm-project/pull/101853 this started emitting
warnings when building / testing the C library. This source file is
shared with the overlay tests as well as the full build tests. The full
build tests are compiled with `-ffreestanding`, as are all the startup /
integration files. The standard says freestanding environment are all
implementation defined, so this is valid in those cases. This patch
simply prevents adding the linkage when we are compiling unit tests,
which are hosted. This is a continuation on
https://github.com/llvm/llvm-project/pull/102825.
Summary:
Currently we have several hacks to work around the fact that the NVPTX
linker, 'nvlink', does not support static libraries or LTO linking.
The patch in https://github.com/llvm/llvm-project/pull/96561 introduces
a wrapper in the toolchain that allows us to use a standard `ld.lld`
like interface. This means all the divergence with this target can be
removed.
Depends on https://github.com/llvm/llvm-project/pull/96561
This patch increases the timeout of the libc test from 1s to 10s, mostly because rv32 runs in a qemu image and sometimes 1s is just not enough for the test to finish when there are other tests running in parallel
This patch adds two operators delete that are being generated by clang 15 on rv32 (operator delete(void *mem, std::align_val_t)) and by gcc 13 on intel 64 (operator delete(void *mem, unsigned long)).
clock() returns a clock_t, which is a long and might overflow in 32-bit
systems when the test takes a long time to run. Changing it to uint64_t
fixes this issue. Before:
[ RUN ] LlvmLibcHashTest.Avalanche
[ OK ] LlvmLibcHashTest.Avalanche (18446744073709551138 ms)
After this patch:
[ RUN ] LlvmLibcHashTest.Avalanche
[ OK ] LlvmLibcHashTest.Avalanche (4154 ms)
Summary:
Not all platforms support this function or header, but it was being
included by every test. Move it inside of the `ifdef` for the only user,
which is aarch64.
Reverts llvm/llvm-project#95419 and Reland #95358.
This PR is full of temporal fixes. After a discussion with @lntue, it is
better to avoid further changes to the cmake infrastructure for now as a
rework to the cmake utilities will be landed in the future.
These changes slighly modify the output of the unittests so that they better
match GTest, so that utilities that parse the expected output from GTest (such
as Android's unit test harness) can read the output from our unit tests.
This allows our unit tests to be run on Android devices.
Add very primitive command line parsing to:
- support --gtest_color=no to disable printing terminal colors.
- recognize --gtest_print_time and print the test time in milliseconds.
- most of our unit tests run on the order of microseconds, so its useful to
preserve the existing behavior. But upsteram GTest ONLY prints time tests
in milliseconds, and Android's atest expects to be able to parse exactly
that. Atest always passes --gtest_print_time. The word `took` is removed as
that also differs from upstream GTest, tripping up parsers.
- ignore other --gtest_* flags
Do so so that atest can parse the output correctly.
Print the test number count before
each run, so that atest can parse this value correctly.
Link: https://android-review.googlesource.com/c/platform/external/llvm-libc/+/3107252
Link: https://google.github.io/googletest/advanced.html#colored-terminal-output
Link: https://google.github.io/googletest/advanced.html#suppressing-the-elapsed-time
Adds more FP test macros for the upcoming test adds for #61092 and the
issues opened from it: #88768, #88769, #88770, #88771, #88772.
Fix bug in `{EXPECT,ASSERT}_FP_EXCEPTION`. `EXPECT_FP_EXCEPTION(0)`
seems to be used to test that an exception did not happen, but it always
does `EXPECT_GE(... & 0, 0)` which never fails.
Update and refactor tests that break after the above bug fix. An
interesting way things broke after the above change is that
`ForceRoundingMode` and `quick_get_round()` were raising the inexact
exception, breaking a lot of the `atan*` tests.
The changes for all files other than `FPMatcher.h` and
`libc/test/src/math/smoke/RoundToIntegerTest.h` should have the same
semantics as before. For `RoundToIntegerTest.h`, lines 56-58 before the
changes do not always hold since this test is used for functions with
different exception and errno behavior like `lrint` and `lround`. I've
deleted those lines for now, but tests for those cases should be added
for the different nearest int functions to account for this.
Adding @nickdesaulniers for review.
This adds a new test fixture class FEnvSafeTest (usable as a base
class for other fixtures) that ensures each test doesn't perturb
the `fenv_t` state that the next test will start with. It also
provides types and methods tests can use to explicitly wrap code
under test either to check that it doesn't perturb the state or
to save and restore the state around particular test code.
All the fenv and math tests are updated to use this so that none
can affect another. Expectations that code under test and/or
tests themselves don't perturb state can be added later.
This replaces the old macros LIBC_COPT_TEST_USE_FUCHSIA and
LIBC_COPT_TEST_USE_PIGWEED with LIBC_COPT_TEST_ZXTEST and
LIBC_COPT_TEST_GTEST, respectively. These are really not about
whether the code is in the Fuchsia build or in the Pigweed build,
but just about what test framework is being used. The gtest
framework can be used in many contexts, and the zxtest framework
is not always what's used in the Fuchsia build.
The test/UnitTest/Test.h wrapper header now provides the macro
LIBC_TEST_HAS_MATCHERS() for use in `#if` conditionals on use of
gmock-style matchers, replacing `#if` conditionals that test the
framework selection macros directly.
Context: https://github.com/llvm/llvm-project/pull/87017
- Add proxy header `libc/hdr/math_macros.h` that will:
- include `<math.h>` in overlay mode,
- include `"include/llvm-libc-macros/math-macros.h"` in full build mode.
- Its corresponding CMake target `libc.hdr.math_macros` will only depend
on `libc.include.math` and `libc.include.llvm-libc-macros.math_macros`
in full build mode.
- Replace all `#include "include/llvm-libc-macros/math-macros.h"` with
`#include "hdr/math_macros.h"`.
- Add dependency to `libc.hdr.math_macros` CMake target when using
`add_fp_unittest`.
- Update the remaining dependency.
- Update bazel overlay: add `libc:hdr_math_macros` target, and replacing
all dependency on `libc:llvm_libc_macros_math_macros` with
`libc:hdr_math_macros`.
