We expect to eventually provide a complete implementation, but having an
empty definition is necessary to unblock the use of libc++ in embedded
environments.
See #84884 for more details.
Fixes#84658.
Assuming these were typos in the first place.
I am unsure of the best way to ensure that both sides of the
preprocessor condition in
`libc/include/llvm-libc-macros/stdbit-macros.h` are tested. Could
someone point me in the right direction for adding test coverage to the
non `__cplusplus` branch? Or maybe it is being tested and I've missed
it.
Summary:
I've noticed one problem is that the user includes `stdint.h` the
compiler will do `#include_next <stdint.h>` potentially into a
conflicting implementation on systems with multiple headers installed.
The `clang` header is standards compliant and works with `clang` and
`gcc` which are both of our targets, so I simply copied it here. This
has the effect of including `stdint.h` on clang / LLVM libc behaving the
same as `-ffreestanding`.
Towards the goal of getting `ninja libc-lint` back to green, fix the numerous
instances of:
warning: header guard does not follow preferred style [llvm-header-guard]
This is because many of our header guards start with `__LLVM` rather than
`LLVM`.
To filter just these warnings:
$ ninja -k2000 libc-lint 2>&1 | grep llvm-header-guard
To automatically apply fixits:
$ find libc/src libc/include libc/test -name \*.h | \
xargs -n1 -I {} clang-tidy {} -p build/compile_commands.json \
-checks='-*,llvm-header-guard' --fix --quiet
Some manual cleanup is still necessary as headers that were missing header
guards outright will have them inserted before the license block (we prefer
them after).
Summary:
Recent changes added an include path in the float128 type that used the
internal `libc` path to find the macro. This doesn't work once it's
installed because we need to search from the root of the install dir.
This patch adds "include/" to the include path so that our inclusion
of installed headers always match the internal use.
Summary:
A lot of these tests failed previously and were disabled. However we
have fixed some things since then and many of these seem to pass.
Additionally, the last remaining math tests that failed seemed to be due
to the exception handling. For now we just set it to be 'errno'.
These pass locally when tested on a gfx1030, gfx90a, and sm_89
architecture. Hopefully these pass correctly on the sm_60 bot as I've
had things fail on that one only before.
While these names are technically internal implemenetation detail,
there's an existing code which relies on these details and using
different names makes LLVM libc implementation incompatible. Since our
goal is for LLVM libc to be a drop in replacement, use the same name as
BSD sys/queue.h version.
Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary changes
here.
This patch completely reworks how the GPU build is built and targeted.
Previously, we used a standard runtimes build and handled both NVPTX and
AMDGPU in a single build via multi-targeting. This added a lot of
divergence in the build system and prevented us from doing various
things like building for the CPU / GPU at the same time, or exporting
the startup libraries or running tests without a full rebuild.
The new appraoch is to handle the GPU builds as strict cross-compiling
runtimes. The first step required
https://github.com/llvm/llvm-project/pull/81557 to allow the `LIBC`
target to build for the GPU without touching the other targets. This
means that the GPU uses all the same handling as the other builds in
`libc`.
The new expected way to build the GPU libc is with
`LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`.
The second step was reworking how we generated the embedded GPU library
by moving it into the library install step. Where we previously had one
`libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This
patch includes the necessary clang / OpenMP changes to make that not
break the bots when this lands.
We unfortunately still require that the NVPTX target has an `internal`
target for tests. This is because the NVPTX target needs to do LTO for
the provided version (The offloading toolchain can handle it) but cannot
use it for the native toolchain which is used for making tests.
This approach is vastly superior in every way, allowing us to treat the
GPU as a standard cross-compiling target. We can now install the GPU
utilities to do things like use the offload tests and other fun things.
Some certain utilities need to be built with
`--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine
workaround as we
will always assume that the GPU `libc` is a cross-build with a
functioning host.
Depends on https://github.com/llvm/llvm-project/pull/81557
Now that `__FRACT_FBIT__` and related macros are added in
https://github.com/llvm/llvm-project/pull/81207, it is safer to use them
for fixed point support detection, so that codes that do not use fixed
point types will not fail to build when `-ffixed-point` is missing.
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
Use definitions from `<linux/mman.h>` to dispatch arch-specific flag
values.
For example, `MCL_CURRENT/MCL_FUTURE/MCL_ONFAULT` are different on
different architectures.
The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.
The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.
The standard requires `limits.h` constants to be used in preprocessors.
So we use `__SIZEOF_LONG__` instead of `sizeof(long)` to define
`LONG_WIDTH`. The macro `__SIZEOF_LONG__` seems to be available on both
clang and gcc since at least version 9.
