This PR intends to fix the nit (mostly caused during the refactor in
693a018dcf08e )
- During refactor we move the implementation along with the explanation
comments to header.
```CPP
// This is an algorithm for log(x) in single precision which is correctly
// rounded for all rounding modes, based on the implementation of log(x) from
// the RLIBM project at:
// https://people.cs.rutgers.edu/~sn349/rlibm
// Step 1 - Range reduction:
// For x = 2^m * 1.mant, log(x) = m * log(2) + log(1.m)
// If x is denormal, we normalize it by multiplying x by 2^23 and subtracting
.....
// Symposium on Principles of Programming Languages (POPL-2022), Philadelphia,
// USA, January 16-22, 2022.
// https://people.cs.rutgers.edu/~sn349/papers/rlibmall-popl-2022.pdf
```
Though the explanation comments were copied and moved to header in
d2492c1 . It wasn't deleted from the `cpp` file.
Along with this in the same,
`#include "src/__support/math/logf.h" // Lookup table for (1/f) and
log(f)`
is wrong as it is actually for
`#include "src/__support/math/common_constants.h" // Lookup table for
(1/f) and log(f)`
Fixesllvm/llvm-project#123821.
Re-enabling pthread docs created a global CMake utility target named
`pthread`, which collides in combined runtime builds where `pthread` is
expected to be a library name. Namespace the internal libc docgen helper
targets under `libc-docgen-*` and restore the generated pthread docs
page. `docs-libc-html` is unchanged.
Summary:
One of the main disadvantages to using the RPC interface is that it
requires a server thread to spin on the mailboxes checking for work.
The vast majority of the time, there will be no work and work will come
in large bursts.
The HSA / KFD interface supports device-side interrupts and already has
handling for binding these events to an HSA signal. This means that we
can send interrupts from the GPU to wake a sleeping thread on the CPU.
The sleeping thread will be descheduled with a blocking HSA wait call
and woken up when its event ID is raised through the kernel driver's
interrupt.
This is very target-specific handling, but I believe it is valuable
enough to warrant it being in the protocol. It is completely optional,
as it is ignored if uninitialized. This should bring this support at
parity with the interface HIP expects.
This PR intends to make the cbrtf guard sync with the general format (
as other functions consistently use `LLVM_LIBC_SHARED_MATH_<func>_H`).
This was found during refactoring cbrtbf16.
Updated LibcTest to handle Windows test executables:
* Added support for .exe extensions when identifying test executables.
* Skipped the executable bit check on Windows as it is not applicable.
* Updated .params file discovery to look for both <test>.exe.params and
<test>.params.
This allows running libc tests on Windows hosts.
This PR intends to add/update the following things:
- Add missing doc for CMake for shared_math
- Add missing testing command for shared_math_test
- Nits (e.g., grammar, spaces, missing colons, etc.)
Lay the ground for C++26 `constexpr` math functions:
- Introduce `LIBC_ENABLE_CONSTEXPR` macro switch to specify the desire
of `constexpr`-only code route.
- Introduce `LIBC_HAS_CONSTANT_EVALUATION` to indicate that we are using
`constexpr`-only code in all dependent functions.
- Introduce `LIBC_CONSTEXPR` macro qualifier to aid in altering the
signature of non-`constexpr` functions.
Note that non-`constexpr` qualified functions are caused by the
exploitation of non-`constexpr` compatible utils, resulting in
non-qualified dependent function, but it can be modified to be qualified
using other code routes.
If the function is `constexpr` compatible, then it's prohibited to use
`LIBC_CONSTEXPR` as a function qualifier. We only qualify it with
`constexpr` as usual.
`LIBC_CONSTEXPR` may or may not evaluate to `constexpr` depending on the
environment configurations, thus it's only used to modify the function
signature in constant evaluation context and remove the qualifier if
it's not desired (depending on provided configurations).
Possible side effects:
- Current qualified routes may or may not produce the desired ULP, this
is implementation dependent (function by function basis) and needs
further testing of the chosen code route.
- The shared tests in the current configuration can still compile with
unsupported compiler. I didn't want to raise compilation error with
unsupported compilers now, but we need to push compiler support with
newer versions for this one to work as intended.
Restructured the Getting Started guide into a numbered step-by-step path
for easier readability. Added a Hello World verification step to confirm
build integrity after build completion.
Additionally, updated build_concepts.rst and the Getting Started guide
to clarify that Overlay Mode is intended for augmenting the system's C
library rather than incremental adoption.
[libc][docs][NFC] Add Build Concepts page with five build scenarios
Added build_concepts.rst defining the five ways to build LLVM-libc:
overlay, full build, bootstrap, cross-compiler, and bootstrap
cross-compiler. Updated full_host_build.rst to cross-reference the new
concepts page for both the runtimes and bootstrap build sections, and
removed a duplicate GWP_ASAN flag from the sysroot CMake recipe. Added
the new page to index.rst.
This adds LIBC_CONF_PRINTF_MODULAR, which causes floating point support
(later, others) to be weakly linked into the implementation.
__printf_modular becomes the main entry point of the implementaiton, an
printf itself wraps __printf_modular. printf it also contains a
BFD_RELOC_NONE relocation to bring in the float aspect.
See issue #146159 for context.
Summary:
Integrated a series of quick documentation cleanups for LLVM-libc. This
update focuses on de-duplicating core conventions (naming and
namespaces) across multiple developer and contribution guides, and
addresses empty platform stubs for UEFI.
Changes:
* libc/docs/contributing.rst: Removed duplicated code style rules and
provided a link to dev/code_style.rst.
* libc/docs/dev/clang_tidy_checks.rst: Removed redundant namespace
explanations and linked to dev/code_style.rst.
* libc/docs/dev/implementation_standard.rst: Removed repetitive notes
about LIBC_NAMESPACE_DECL and linked to the authoritative reference.
* libc/docs/uefi/support.rst & libc/docs/uefi/using.rst: Added
early-stage bring-up warnings and pointed to the config directory for
the source of truth.
generate_config_doc() was writing configure.rst directly into the source
tree, which fails when building from a read-only source directory (e.g.
when the source is on a read-only filesystem or in a packaging
environment).
The Sphinx build in libc/docs/CMakeLists.txt already copies static .rst
files from the source tree into the build tree so that generated docs
don't pollute the source directory. Move configure.rst generation to
follow this same pattern by writing to LIBC_BUILD_DIR/docs/ instead of
LIBC_SOURCE_DIR/docs/.
This also removes configure.rst from the checked-in source tree, since
it was fully generated content that was being regenerated on every CMake
configure anyway.
The `generic_as` function in `dyadic_float.h` had a missing `underflow =
true` at the exact boundary where `unbiased_exp == -EXP_BIAS -
FRACTION_LEN`.
At this boundary, the mantissa MSB maps exactly to the round bit, so
out_mantissa is 0 and the result can only be 0 or min_subnormal. The
value is at most min_subnormal / 2, so it is always tiny and always
inexact `underflow` must be signaled. The < case and the general
subnormal range both already set underflow = true this boundary case was
the only gap.
this specifically fix this error in the erfcf16 function
```
Extracted erfcf16.cpp.o from archive for linking
Running exhaustive check in --rndn mode...
Missing underflow exception for x=0x1.eacp+1 (y=0x1p-24)
```
this fix may also apply to other bfloat16 missing exceptions
(@Sukumarsawant)
part of: #186483
CC: @lntue
For ASCII systems, b36_char_to_int gets compiled into a jump table. That
jump table ends up being pretty large because it covers the range from
'0' (48) to 'z' (122). On size-constrained systems that can assume
ASCII, this patch provides a new flag: LIBC_CONF_CTYPE_SMALLER_ASCII
that forces a smaller implementation that doesn't compile into a jump
table.
Added entrypoints:
- baremetal/arm
- baremetal/aarch64
- baremetal/riscv
- darwin/aarch64
- linux/aarch64
- linux/arm
- linux/riscv
- linux/x86_64
- windows
Also added the unit test for iswpunct.
Part of the issue: #185136
This patch initiates the refactoring of Linux syscalls as described in
the RFC (https://discourse.llvm.org/t/rfc-linux-syscall-cleanup/87248/).
It introduces a new infrastructure in
`src/__support/OSUtil/linux/syscall_wrappers/` to house header-only
syscall wrappers. These wrappers utilize `ErrorOr` to provide a
consistent, type-safe interface for error handling across the library,
standardizing how syscall return values are converted into
errno-compatible Error objects.
Summary of changes:
- Created the `syscall_wrappers` directory and added `close.h`,
`read.h`, `write.h`, and `open.h`.
- Moved the existing `getrandom.h` into the new `syscall_wrappers`
directory and updated its callers (including HashTable/randomness.h).
- Refactored core entrypoints (`close`, `read`, `write`, `open`) to use
the new wrappers, removing direct `syscall_impl` logic and manual errno
setting.
- Updated `shm_open.cpp` to use the new `open` wrapper.
- Cleaned up `OSUtil/linux/fcntl.cpp` by removing redundant internal
implementations of `open` and `close`.
- Added a developer guide in `docs/dev/syscall_wrapper_refactor.rst`
outlining the established pattern for future migrations.
---------
Co-authored-by: Michael Jones <michaelrj@google.com>
When building the full library with -nostdinc, directly including
<stdint.h> may pull in host or compiler-provided headers that collide
with LLVM-libc's local macro definitions. Switch to using our internal
stdint-macros.h when LIBC_FULL_BUILD is enabled.
Additionally, declare aligned_alloc with noexcept in C++ to match common
C library declarations and avoid fatal type specification mismatches
during sysroot builds.
Add Jeff Bailey as a maintainer for General Maintenance and
Documentation. Jeff has been contributing to LLVM-libc since January
2022. This addition was discussed at the most recent LLVM-libc meeting
with no objections raised.
The tests:
- __support/freelist_heap_fuzz.cpp
- fuzzing/string/strlen_fuzz.cpp
had build failures for different reasons. This patch fixes these
failures.
freelist_heap_fuzz.cpp had this error:
```
llvm-project/libc/fuzzing/__support/freelist_heap_fuzz.cpp:150:26: error: use of undeclared identifier 'Block'; did you mean '__llvm_libc_23_0_0_git::Block'?
150 | size_t alignment = Block::MIN_ALIGN;
| ^~~~~
| __llvm_libc_23_0_0_git::Block
```
The issue stems from the fact that Block was not available in scope. It
needs to be referenced via LIBC_NAMESPACE.
strlen_fuzz.cpp had this error:
```
In file included from Workspace/llvm-project/libc/fuzzing/string/strlen_fuzz.cpp:14:
In file included from /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/cstdint:38:
In file included from /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/x86_64-linux-gnu/c++/13/bits/c++config.h:679:
/usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/x86_64-linux-gnu/c++/13/bits/os_defines.h:44:5: error: function-like macro '__GLIBC_PREREQ' is not defined
44 | #if __GLIBC_PREREQ(2,15) && defined(_GNU_SOURCE)
```
This issue is more cryptic to me, but I managed to fix it by changing
the includes from cstdint and cstring to stdint.h and string.h.
Add support for %ls in printf by calling internal string converter and
add relevant end-to-end sprintf test. Additionally, modified printf
parser for recognizing length modifier. This also disables wide string
support on windows
and other unsupported platforms.
Co-authored-by: shubhe25p <shubhp@mbm3a24.local>
