Add dependency on headers with `in_addr` and `in_addr_t` type
definitions to ensure that these headers will be properly installed by
"install-libc" CMake target.
Algorithm:
```
1) atan(x) = sign(x) * atan(|x|)
2) If |x| > 1 + 1/32, atan(|x|) = pi/2 - atan(1/|x|)
3) For 1/16 < |x| < 1 + 1/32, we find k such that: | |x| - k/16 | <= 1/32.
Let y = |x| - k/16, then using the angle summation formula, we have:
atan(|x|) = atan(k/16) + atan( (|x| - k/16) / (1 + |x| * k/16) )
= atan(k/16) + atan( y / (1 + (y + k/16) * k/16 )
= atan(k/16) + atan( y / ((1 + k^2/256) + y * k/16) )
4) Let u = y / (1 + k^2/256), then we can rewritten the above as:
atan(|x|) = atan(k/16) + atan( u / (1 + u * k/16) )
~ atan(k/16) + (u - k/16 * u^2 + (k^2/256 - 1/3) * u^3 +
+ (k/16 - (k/16)^3) * u^4) + O(u^5)
```
With all the computations are done in single precision (float), the
total of approximation errors and rounding errors is bounded by 4 ULPs.
Summary:
These were originally intended to represent the functions that are
present on the GPU as to be provided by the LLVM libc implementation.
The original plan was that LLVM libc would report which functions were
supported and then the offload interface would mark those as supported.
The problem is that these wrapper headers are very difficult to make
work given the various libc extensions everyone does so they were
extremely fragile.
OpenMP already declares all functions used inside of a target region as
implicitly host / device, while these headers weren't even used for CUDA
/ HIP yet anyway. The only things we need to define right now are the
stdio FILE types. If we want to make this work for CUDA we'd need to
define these manually, but we're a ways off and that's way easier
because they do proper overloading.
Explicitly cast 0 to size_t type to match fread() return type. This
follows the pattern used elsewhere in this file, and fixes
-Wshorten-64-to-32 warnings when building the test.
This patch provides definitions for `pkey_*` functions for linux x86_64.
`pkey_alloc`, `pkey_free`, and `pkey_mprotect` are simple syscall
wrappers. `pkey_set` and `pkey_get` modify architecture-specific
registers. The logic for these live in architecture specific
directories:
* `libc/src/sys/mman/linux/x86_64/pkey_common.h` has a real
implementation
* `libc/src/sys/mman/linux/generic/pkey_common.h` contains stubs that
just return `ENOSYS`.
This patch adds the posix function `inet_addr`. Since most of the
parsing logic is delegated to `inet_aton`, I have only included some
basic smoke tests for testing purposes.
These functions should be declared in `stdlib.h`, not `wchar.h`, as
confusing as it is. Move them to the proper header file and matching
directories in src/ and test/ trees.
This was discovered while testing libc++ build against llvm-libc, which
re-declares functions like mbtowc in std-namespace in `<cstdlib>`
header, and then uses those functions in its locale implementation.
These are simply implemented as specializations of strtofloatingpoint
for double / long double and for wchar_t. The unit tests are copied from
the strtod / strtold ones.
Currently there are no 32 bit presubmit builds for libc. This PR
performs 32 bit build only (no test) to check any changes that land in
libc break 32 bit builds.
Co-authored-by: Aiden Grossman <aidengrossman@google.com>
_Exit(3) is a fairly simple syscall wrapper whereas exit(3) calls
atexit-registered functions + whole lot of stuff that require support
for sync primitives.
Splitting the tests allows testing the former easily (especially for new
port projects)
---------
Signed-off-by: Shreeyash Pandey <shreeyash335@gmail.com>
Addresses `TODO`s in file.cpp by replacing data copies via for loops
with calls to inline_memcpy.
Signed-off-by: Shreeyash Pandey <shreeyash335@gmail.com>
This change follows the pattern of
315dfe5865962d8a3d60e21d1fffce5214fe54ef by making strtofloat also
accept wchar_t* strings
(in addition to regular char*). It uses overloads from wctype_utils or
specialized functions to ensure comparison with literal characters (or
literal strings) pick char or wchar_t variants based on the argument
type.
The wcstof implementation is added, with unit test cases copied from
strtof test suite.
[libc][stdlib] Simplify getenv_test by using inline_strcmp instead of custom helper
Replace the custom `my_streq` helper function with LLVM libc's
`inline_strcmp` utility from `src/string/memory_utils/inline_strcmp.h`.
Changes:
- Remove 18-line custom `my_streq` implementation
- Use `inline_strcmp` with a simple comparator lambda for string comparisons
- Replace `my_streq(..., nullptr)` checks with direct `== nullptr` comparisons
- Maintain identical test coverage while reducing code duplication
Benefits:
- Uses existing, well-tested LLVM libc infrastructure
- Clearer test assertions with standard comparison functions
- More concise code (reduced from ~48 to ~33 lines)
- Consistent with LLVM libc coding practices
The test continues to verify:
- Empty string handling
- Invalid name handling ('=')
- Missing environment variable queries
- Correct retrieval of existing variables (FRANCE, GERMANY, PATH)
- Partial name matching behavior (FRANC vs FRANCE, FRANCE1 vs FRANCE)
When the backend for the host target isn't enabled, Clang would report
the default target as `unknown`. This currently breaks the libc CMake
build, but shouldn't in the case where we're cross-compiling since we're
given an explicit target and the default one isn't being used.
The LLVM-customized GTest has a dependency on LLVM to support
`llvm::raw_ostream` and hence has to link to LLVMSupport. The runtimes
use the LLVMSupport from the bootstrapping LLVM build. The problem is
that the boostrapping compiler and the runtimes target can diverge in
their ABI, even in the runtimes default build. For instance, Clang is
built using gcc which uses libstdc++, but the runtimes is built by Clang
which can be configured to use libcxx by default. Altough it does not
use gcc, this issue has caused
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89)) to
break, and is still (again?) broken.
This patch makes the runtimes' GTest independent from LLVMSupport so we
do not link any runtimes component with LLVM components.
Runtime projects that use GTest unittests:
* flang-rt
* libc
* compiler-rt: Adds `gtest-all.cpp` with
[GTEST_NO_LLVM_SUPPORT=1](f801b6f67e/compiler-rt/CMakeLists.txt (L723))
to each unittest without using `llvm_gtest`. Not touched by this PR.
* openmp: Handled by #159416. Not touched for now by this PR to avoid
conflict.
The current state of this PR tries to reuse
https://github.com/llvm/llvm-project/blob/main/third-party/unittest/CMakeLists.txt
as much as possible, altough personally I would prefer to make it use
"modern CMake" style. third-party/unittest/CMakeLists.txt will detect
whether it is used in runtimes build and adjaust accordingly. It creates
a different target for LLVM (`llvm_gtest`, NFCI) and another one for the
runtimes (`runtimes_gtest`). It is not possible to reuse `llvm_gtest`
for both since `llvm_gtest` is imported using `find_package(LLVM)` if
configured using LLVM_INSTALL_GTEST. An alias `default_gtest` is used to
select between the two. `default_gtest` could also be used for openmp
which also supports standalone and
[LLVM_ENABLE_PROJECTS](https://github.com/llvm/llvm-project/pull/152189)
build mode.
ctype_utils/wctype_utils were chaged in
120689e46679c6db37cd9e839ec0721e80a22d4f and
e7f7973899f76773ae6e9a6b1e8c7e9f9cc5cb56, respectively to operate on
char/wchar_t. Now we can switch to the overloaded names (e.g. have noth
`isspace(char` and `isspace(wchar_t)`) to simplify the templatized
strtointeger implementation from
315dfe5865962d8a3d60e21d1fffce5214fe54ef and make it easier to
potentially add templatized strtofloat implementation.
There is no guarantee that this environment variable is set. Eg, when
running a test outside of the build system, such as under a debugger.
And passing a nullptr to the string constructor is undefined.
Use an empty string, which seems like it is close to the original
intent.
Closes#161461
- This is my first time contributing to libc's POSIX, so for reference I
used `clock_gettime` implementation for Linux. For convenience, here is
the description of `clock_settime` function
[behavior](https://www.man7.org/linux/man-pages/man3/clock_settime.3.html)
fwrite and friends don't modify errno if no error occurred. Therefore
frite_unlocked's return value shouldn't be constructed from errno
without checking if an error actually occurred.
This fixes an error introduced by
9e2f73fe90
This patch adds `acos` to the entrypoints of baremetal Arm and AArch64.
Tests have been run with Arm Toolchain for Embedded, a downstream
toolchain, in conjunction with qemu, across several configurations of
FPUs and architecture versions. All tests run are passing.
Looks like https://github.com/llvm/llvm-project/pull/166517 is breaking
libc-riscv32-qemu-yocto-fullbuild-dbg build due to failing overflow test
for strfrom.
https://lab.llvm.org/buildbot/#/changes/58668
```
int result = func(buff, sizeof(buff), "%.2147483647f", 1.0f);
EXPECT_LT(result, 0);
ASSERT_ERRNO_FAILURE();
```
```
[ RUN ] LlvmLibcStrfromdTest.CharsWrittenOverflow
/home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:493: FAILURE
Expected: result
Which is: 0
To be less than: 0
Which is: 0
/home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:494: FAILURE
Expected: 0
Which is: 0
To be not equal to: static_cast<int>(libc_errno)
Which is: 0
[ FAILED ] LlvmLibcStrfromdTest.CharsWrittenOverflow
Ran 8 tests. PASS: 7 FAIL: 1
```
At first glance it seem like there is some kind of overflow in
internal::strfromfloat_convert on 32bit archs because the other overflow
test case is passing for snprintf. Interestingly, it passes on all other
buildbots, including libc-arm32-qemu-debian-dbg.
This issue likely wasn't introduced by
https://github.com/llvm/llvm-project/pull/166517 and was probably
already present, so I'm not reverting the change just disabling the test
case on riscv32 until I can debug properly.
On exit from the loop, char_ptr had not been updated to match block_ptr,
resulting in erroneous results. Moving all updates out of the loop fixes
that.
Adjust derefences to always be inside bounds checks.
This patch also configures fcntl lock tests to run with F_OFD_* command
variants, as all existing lock tests do not exercise process-associated-
or OFD-specific functionality.
This patch defines errno unit and integration test asserts as noop on
GPU targets. Checking for errnos is tests has caused build breakages in
previous patches.
This is a counterpart of
https://github.com/llvm/llvm-project/pull/166225 but for wctype_utils
(which are not yet widely used). For now, I'm just changing the types
from wint_t to wchar_t to match the regular ctype_utils change. The next
change may rename most of the functions to match the name of ctype_utils
variants, so that we could be calling them from the templated code
operating on "const char*" and "const wchar_t*" strings, and the right
function signature would be picked up.
Functions like isalpha / tolower can operate on chars internally. This
allows us to get rid of unnecessary casts and open a way to creating
wchar_t overloads with the same names (e.g. for isalpha), that would
simplify templated code for conversion functions (see
315dfe5865962d8a3d60e21d1fffce5214fe54ef).
Add the int->char converstion to public entrypoints implementation
instead. We also need to introduce bounds check on the input argument
values - these functions' behavior is unspecified if the argument is
neither EOF nor fits in "unsigned char" range, but the tests we've had
verified that they always return false for small negative values. To
preserve this behavior, cover it explicitly.
This patch refactors the logic to define each component of the
`math_errhandling` macro.
It assumes that math error handling is supported by the target and the C
library unless otherwise disabled in the preprocessor logic.
In addition to the refactoring, the support for error handling via
exceptions is explicitly disabled for Arm targets with no FPU, that is,
where `__ARM_FP` is not defined. This is because LLVM libc does not
provide a floating-point environment for Arm no-FP configurations (or at
least one with support for FP exceptions).
The `FEnvSafeTest.cpp` test fails on AArch64 soft nofp configurations
because LLVM libc does not provide a floating-point environment in these
configurations.
This patch adds another preprocessor guard on `__ARM_FP` to disable the
test on those.
