This header is needed to provide the declaration for the sqrt template.
You can build without these in the CMake build, but not having this
include in the architecture specific headers makes them not self
contained.
Fixes#133365
## Changes Done
- Changed the signed checking to
```cpp
struct is_signed : bool_constant<((is_fixed_point<T> || is_arithmetic_v<T>) && (T(-1) < T(0)))>
```
in ``/libc/src/__support/CPP/type_traits/is_signed.h``. Added check for
fixed-points.
- But, got to know that this will fail for ``unsigned _Fract`` or any
unsigned fixed-point because ``unsigned _Fract`` can’t represent -1 in
T(-1), while ``unsigned int`` can handle it via wrapping.
- That's why I explicity added ``is_signed`` check for ``unsigned``
fixed-points.
- Same changes to ``/libc/src/__support/CPP/type_traits/is_unsigned.h``.
- Added tests for ``is_signed`` and ``is_unsigned``.
Fix two instances of libcxx_shared_headers depending on .cpp files (in
Bazel build):
* Don't depend on exit syscall in LIBC_ASSERT implementation. This
dependency is not used, since LIBC_ASSERT always uses system <assert.h>
in the overlay mode, which is the only mode supported by Bazel.
* Don't depend on libc_errno in str-to-float and str-to-integer
conversions. We only need the ERANGE value, which can be obtained from
the proxy header instead.
The entrypoints for aarch64 are mostly up to date, but the headers are
not. This patch fixes that, and also makes explicit the dependency from
OSUtils/linux on sys/syscalls.h
nexttowardf16_test is resulting in calling shift and for some reason not
meeting the invariant where offset is less than bits. Change the if
statement to directly check if shift - 1 meets the conditions.
The rounding of the result when using an FMA instruction for hyperbolic
sin/cos on float16 was off by 1 bit for a few cases. This patch adds
extra exceptional cases to handle these.
Summary:
C++20 introduced an atomic reference type, which more easily wraps
around the standard way of dealing with atomics. Instead of a dedicated
type, it allows you to treat an existing allocation as atomic.
This has no users yet, but I'm hoping to use it when I start finalizing
my GPU allocation interface, as it will need to handle atomic values
in-place that can't be done with placement new. Hopefully this is small
enough that we can just keep it in-tree until it's needed, but I'll
accept holding it here until it has a user.
I added one extension to allow implicit conversion and CTAD.
Summary:
There were a few issues with the first one, leading to some errors and
warnings. Most importantly, this was building on MSVC which isn't
supported.
Summary:
We have 'generic' implementations for some functions stdio functions.
The current logic mandates that all generic functions are implemented by
the target. This obviously isn't true and this caused the GPU builds to
fail once baremtal added some extra ones.
This patch changes the logic to always include the generic sources only
if they aren't already defined. This can probably be cleaned up and
formalized later, since this pattern is copied in many places, but for
now this fixes the failing GPU build bots.
This PR adds the missing opening parenthesis for sollya command comment
in `libc/src/math/generic/cbrtf.cpp#L28`.
Signed-off-by: krishna2803 <kpandey81930@gmail.com>
This PR implements the following macros for `sched.h`:
- `CPU_ZERO`
- `CPU_ISSET`
- `CPU_SET`
Fixes#124642
---------
Signed-off-by: krishna2803 <kpandey81930@gmail.com>
This fleshes out the <link.h> a little more, including the
`struct dl_phdr_info` type and declaring the dl_iterate_phdr
function. There is only a no-op implementation without tests, as
for the existing dlfcn functions.
Fixes incorrect logic that went unnoticed until the function was tested
with output and input types that have the same underlying floating-point
format.
This allows specializing the implementation for different targets
without including unnecessary logic and is similar to #111559 which did
the same for printf Writer interface.
Initial UEFI OS target support after the headers. This just defines
enough that stuff might try and compile. Test with:
```
$ cmake -S llvm -B build -G Ninja -DLLVM_RUNTIME_TARGETS=x86_64-unknown-uefi-llvm -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_ENABLE_RUNTIMES=libc -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_LIBC_FULL_BUILD=true -DCMAKE_C_COMPILER_WORKS=true -DCMAKE_CXX_COMPILER_WORKS=true -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LIBCXX=true -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-uefi-llvm -DCMAKE_INSTALL_LIBDIR=build/target/lib
$ ninja -C build
```
Summary:
Right now a lot of the memory functions error if we don't have specific
handling for them. This is weird because we have a generic
implementation that should just be used whenever someone hasn't written
a more optimized version. This allows us to use the `libc` headers with
more architectures from the `shared/` directory without worrying about
it breaking.
The affected line of code converts a float's exponent from `int` to
`size_t`, negating it in the process. Following clang commit
773e88f9d6, this provokes a warning, presumably because the
conversion goes wrong if `size_t` is wider than `int` and the input
value is `INT_MIN`: negating it within the `int` type is undefined
behavior, with the likely (though not guaranteed) effect of leaving it
still at `INT_MIN` and then sign-extending that on promotion to
`size_t`.
This fix adds a cast so that the promotion to `size_t` happens _before_
the negation, so that the negative input value will _always_ be
sign-extended, and then the negation will make it positive again.
(I don't believe this case will actually come up. `DyadicFloat` is a
helper system used in processing ordinary float formats, so nothing is
expected to generate an exponent with even a 16-bit absolute value, let
alone 31. But it's as easy to fix it to be robust as it is to just
suppress the warning!)
Summary:
This patch moves the RPC server handling to be a header only utility
stored in the `shared/` directory. This is intended to be shared within
LLVM for the loaders and `offload/` handling.
Generally, this makes it easier to share code without weird
cross-project binaries being plucked out of the build system. It also
allows us to soon move the loader interface out of the `libc` project so
that we don't need to bootstrap those and can build them in LLVM.
Commit 598e882ee8 turned `Writer` into a template, and updated most
of the call sites that use it. But not all. The alternative FP printf
system in `float_dec_converter_limited.h` wasn't updated, and neither
was `baremetal/printf.cpp` or `baremetal/vprintf.cpp`.
This patch updates `float_dec_converter_limited.h` in the same way that
the previous commit updated `float_dec_converter.h`: propagate the
templatedness through everything in the header, so that anything using a
`Writer` at all has a `write_mode` template parameter to pass on to it.
`printf.cpp` and `vprintf.cpp` are updated in the same way that the
previous commit updated `printf_core/vfprintf_internal.h`: the
`WriteBuffer` has parameter `WriteMode::FLUSH_TO_STREAM`, and `Writer`
picks it up implicitly from that.
Summary:
Currently we dispatch the writing mode off of a runtime enum passed in
by the constructor. This causes very unfortunate codegen for the GPU
targets where we get worst-case codegen because of the unused function
pointer for `sprintf`. Instead, this patch moves all of this to a
template so it can be masked out. This results in no dynamic stack and
uses 60 VGPRs instead of 117. It also compiles about 5x as fast.
