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>
The standard streams should be defined the same as other public symbols,
even though they're variables rather than functions: we should have
public and private symbol which are aliases, and all internal uses
should use the private symbol to avoid GOT relocations.
This change introduces a new macro `LLVM_LIBC_VARIABLE` which is the
equivalent of `LLVM_LIBC_FUNCTION` and it refactors the existing
definitions of standard streams for BareMetal, Linux and GPU to use this
macro.
Ref from the build failure in hypotbf16
```CPP
project/libc/src/__support/math/hypotbf16.h:22:33: required from here
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/FPUtil/Hypot.h:221:44: error: conversion from ‘int’ to ‘StorageType’ {aka ‘short unsigned int’} may change value [-Werror=conversion]
221 | r = static_cast<StorageType>((r << 1)) +
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
222 | ((tail_bits & current_bit) ? 1 : 0);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
```
This PR intends to fix that by adding static_cast
The variadic template helper `load_aligned` performs a specific case of
an unaligned integer load, by loading a sequence of integers from memory
at addresses expected to be aligned, and glues the results back together
with shifts and ORs into an output.
The implementation works by performing the first load, recursing on a
shorter parameter type list for the rest, and recombining via
first | (rest << size_of_first) // if little-endian
(first << size_of_first) | rest // if big-endian
But the big-endian case is wrong: it should shift left by the size of
the _rest_ of the types, not the size of the first. In the case where
you load 8, 16 and 8 bits from an odd address, you want
(first_byte << 24) | (middle_halfword << 8) | (last_byte)
but in fact we were calculating
(first_byte << 8) | (middle_halfword << 16) | (last_byte)
leading to three out of every four bytes being permuted in a memcpy from
an odd to an even address.
