Several key targets unconditionally depend on `OSUtil.osutil` target,
causing errors when it is unnecessarily linked, or not available. This
PR fine-tuning the dependency on `OSUtil.osutil` to cleanly decouple
those targets, and gracefully skip targets that need `osutil`. Main
changes include:
* Make `LIBC_COPT_USE_C_ASSERT` to a cmake config, allowing
`LIBC_ASSERT` to use system's `assert` and not depending on `osutil`.
* Adjust cmake dependency for the following targets:
- libc.src.__support.libc_assert
- libc.src.__support.time.*
- libc.src.time.linux.*
- libc.src.unistd.*
- LibcTest
* Give an option for `TestLogger` to use system's `fprintf` instead of
`osutil`.
Updated check-libc-lit to depend only on build-only targets. Added
libc-integration-tests-build to track integration test executables and
updated LLVMLibCTestRules.cmake to populate it.
Removed incorrect dependencies on execution suites in include and
integration tests that were introduced in #184366.
Summary:
This PR primarily changes using `LLVM_RUNTIMES_TARGET` to
`LLVM_DEFAULT_TARGET_TRIPLE`. The reason is that the default target
triple is the true cross-compiling architecture we are using, while the
runtimes_target can contain multilib strings like `+debug` or similar.
Additionally add the proper path handling to the OpenMP / Offload
libraries.
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.
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.
Summary:
This used to be two separate executables but was merged awhile back. The
LLVM libc code was never updated to use the new tool name and a recent
refactoring unintentionally removed the symlinks. Just look for
`llvm-gpu-loader`.
Integration tests with ARGS or ENV in their add_integration_test() call
were being run with no arguments or environment variables by the
LibcTest lit format, causing failures in startup_args_test,
sprintf_size_test, getenv_test, execv_test, execve_test, and
getcwd_test.
Fix this by having add_integration_test() emit a sidecar
<executable>.params JSON file (via file(GENERATE)) whenever ARGS or ENV
are specified. LibcTest.execute() reads this file at test time and
passes the args and environment to the test executable.
Also always set PWD=exec_dir in the test environment so that
getenv("PWD") matches getcwd() for tests that compare them.
Summary:
This patch rewrites the `llvm-gpu-loader` utility to use the LLVMOffload
interface. This heavily simplifies it while re-using the already
existing support. Another benefit is that I can now easily do this
dynamically so we can always build this utility without needing to find
non-standard packages.
One issue is mentioned in
https://github.com/llvm/llvm-project/issues/159636 where this will now
take extra time if you have both installed on the same machine. This is
just slightly annoying since most people don't have both CUDA and ROCm
at the same time so I don't consider it a blocker. I will work later to
address it.
Slightly unfortunate environment variable usage, I will also expose that
better in the future.
Fixes: https://github.com/llvm/llvm-project/issues/132890
Summary:
We spoof the OS name for the GPU targets and used to get it form the
'end' of the triple list. Adding `-llvm` makes that now point to `-llvm`
which is not recognized so it fails. Just use the direct index, we
already guard that the triple is the correct size
This provides optional lit-based test execution for the LLVM Libc tests,
alongside the existing CMake-based test execution.
Usage:
ninja -C build check-libc-lit
cd build && bin/llvm-lit libc/test/src/
Partially addresses
[#118694](https://github.com/llvm/llvm-project/issues/118694). A future
PR once this lands will flip the default (per suggestion in the RFC)
Summary:
We should likely use `-DLLVM_DEFAULT_TARGET_TRIPLE` as the general
source of truth, make the handling work with that since we use it for
the output directories. Fix the creation of startup files in this mode
and make sure it can detect the GPU properly.
Fixes: https://github.com/llvm/llvm-project/issues/179375
The str to float code path offers options which can reduce code bloat.
Expose them as build config options. Disable Eisel Lemire for avoiding
code bloat caused by DETAILED_POWERS_OF_TEN look up table.
In order to apply the stack protector correctly to the compile options,
we need to make sure to use the same config name everywhere.
`LIBC_CONF_ENABLE_STACK_PROTECTOR` seems to be outdated and all other
places specify `LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR` and it should
therefore be updated here as well.
Add support for %lc in printf by calling internal wcrtomb function and
relevant end-to-end sprintf test.
Additionally, made the following changes:
- Modified printf parser for recognizing length modifier
- Added two internal error codes.
- Added a flag to disable wchar support on windows platform.
- To keep printf interface header only, converted wcrtomb and
CharacterConverter to header only implementation and removed the cpp
source.
Resolves GPU libc issues in #169983 and original issue: #166598
---------
Co-authored-by: shubhe25p <shubhp@mbm3a24.local>
Co-authored-by: Joseph Huber <huberjn@outlook.com>
This reverts commit 1327c50ef199b481f5326cf6ca3710fc111b70b1.
The printf headers are intended to be header-only, this introduces
external symbol dependencies.
Add support for %lc in printf by calling internal wcrtomb function and
relevant end-to-end sprintf test. Additionally, modified printf parser
for recognizing length modifier and added two internal error codes. Also
added a flag to disable wchar support on windows platform. Resolves
#166598
Co-authored-by: shubh@DOE <shubhp@mbm3a24.local>
[#172040](https://github.com/llvm/llvm-project/issues/172040)
This patch implements the scripts for generating the lookup tables and
associated utils for wctype classification functions. Not all Unicode
properties are covered as not all need a lookup table, the rest will be
hardcoded. The size of the generated tables is 47,8KB.
This patch implements the generic mutex and raw_mutex interfaces on
macOS. A new Futex class is provided that relies on os_sync_wait and
os_sync_wake to emulate futex‑like wait and wake semantics. The
OS‑specific part is moved into futex_utils, which now contains the
Darwin implementation.
[Previous commit had an incorrect default case when
FIND_FIRST_CHARACTER_WIDE_READ_IMPL was not specified in config.json.
This PR is identical to that one with one line fixed.]
As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.
This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:
1. element, which reads byte-by-byte (or wchar by wchar)
2. wide, which reads by unsigned long
3. generic, which uses standard clang vector implemenations, if
available
4. arch, which uses an architecture-specific implemenation
(Reading the code carefully, you may note that a user can actually
specify any namespace they want, so we aren't technically limited to
those 4.)
We may also want to switch from command-line #defines as it is currently
done, to something more like
llvm-project/llvm/include/llvm/Config/llvm-config.h.cmake, and
complexity out of the command-line. But that's a future problem.
[This is more of a straw-proposal than a ready-for-merging PR. I got
started thinking about what this might look like, and ended up just
implementing something as a proof-of-concept. Totally open to other
methods an ideas.]
As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.
This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:
1. element, which reads byte-by-byte (or wchar by wchar)
2. wide, which reads by unsigned long
3. generic, which uses standard clang vector implemenations, if
available
4. arch, which uses an architecture-specific implemenation
(Reading the code carefully, you may note that a user can actually
specify any namespace they want, so we aren't technically limited to
those 4.)
We may also want to switch from command-line #defines as it is currently
done, to something more like
llvm-project/llvm/include/llvm/Config/llvm-config.h.cmake, and
#including the resulting file, which would move quite a bit of
complexity out of the command-line. But that's a future problem.
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.
_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>
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.
This options sets a compile option when building sources inside the
string directory, and this option affects string_utils.h. But
string_utils.h is #included from more places than just the string
directory (such as from __support/CPP/string.h), leading to both
narrow-reads in those cases, but more seriously, ODR violations when the
two different string_length implementations are included int he same
program.
Having this option at the top level avoids this problem.
Relates to https://github.com/llvm/llvm-project/issues/119281
Note:
1) As this PR enables `-Werror` for `libc` tests, it's very likely some
downstream CI's may fail / start failing, so it's very likely this PR
may need to be reverted and re-applied.
P.S.
I do not have merge permissions, so I will need one of the reviews to
merge it for me. Thank you!
This partially reverts #124200. Rather than using a CMake option to
control whether to enable `-fno-math-errno`, use LIBC_MATH_NO_ERRNO
configuration option. While there might be other cases when we want to
set `-fno-math-errno`, having LIBC_MATH_NO_ERRNO imply it should be
always safe and represents a reasonable starting point.
Summary:
The AMDGPU hack can be removed, and we no longer need to skip 90% of the
`HandleLLVMOptions` if we work around NVPTX earlier. Simplifies the
interface by removing duplicated logic and keeps the GPU targets from
being weirdly divergent on some flags.
Summary:
People might want to modify this to run on older machines. Expose this
so it can be set with
`-DRUNTIMES_amdgcn-amd-amdhsa_LIBC_GPU_CODE_OBJECT_VERSION`.
