This would ensure that errno value is cleared out before test execution
and tests pass even when LIBC_ERRNO_MODE_SYSTEM_INLINE is specified (and
errno may be clobbered before test execution).
A lot of the tests would fail, however, since errno would end up getting
set to EDOM or ERANGE during test execution and never validated before
the end of the test. This should be fixed - and errno should be
explicitly checked or ignored in all of those cases, but for now add a
TODO to address it later (see open issue #135320) and clear out errno in
test fixture to avoid test failures.
Also use ErrnoSetterMatcher to verify the function return values and
verify/clear out errno values. Fix the bug in ErrnoSetterMatcher error
reporting machinery to properly convert errno values into errno names to
make error messages easier to debug.
Use ErrnoCheckingTest harness added in
d039af33096c0a83b03475a240d5e281e2271c44 for all unistd tests that
verify errno values. Stop explicitly setting it to zero in test code, as
harness does it.
It also verifies that the errno is zero at the end of each test case, so
update the ASSERT_ERRNO_EQ and ASSERT_ERRNO_FAILURE macro to clear out
its value after the verification (similar to how ErrnoSetterMatcher
does).
Update the CMake and Bazel rules for those tests. In the latter case,
remove commented out tests that are currently unsupported in Bazel,
since they get stale quickly.
See the discussion in PR
https://github.com/llvm/llvm-project/pull/131650 on why we need to clear
the errno at the beginning of some tests, and outlining the various solutions.
Introduce ErrnoCheckingTest base class and use it for unlink_test as an example.
This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.
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)
