Note: our baremetal arm configuration compiles this as
`--target=arm-none-eabi`, so this code is built in -marm mode. It could be
smaller with `--target=armv7-none-eabi -mthumb`. The assembler is valid ARMv5,
or THUMB2, but not THUMB(1).
Summary:
Currently we use `(~0U)` for this definition, however the ~ operator
returns a different sign, meaning that preprocessor checks against this
value will fail. See https://godbolt.org/z/TrjaY1d8q where the
preprocessor thinks that it's not `0xffffffff` while the static
assertion thinks it is. This is because the latter does implicit
conversion but the preprocessor does not. This is now consistent with
other headers.
New pull request for https://github.com/llvm/llvm-project/issues/89443
The previous PR was reverted after breaking fullbuild due to a missing
struct declaration, which I forgot to commit.
Reverts revert and adds the missing pthread_rwlockattr_getkind_np /
pthread_rwlockattr_setkind_np functions and tests respecitvely.
These are untested and unsupported platforms. The pattern used makes sense for
platform specific error numbers, but these are platforms we do not support.
Excise this code.
Link: #91150
Summary:
Some targets support denormals as floating point exceptions. This is
provided as an extension in the GNU headers as __FE_DENORM.
This provides it in our headers, however I'm unsure if we should make it
internal or external. I do not think it should be in all exception as it
doesn't represent an exceptional behavior as far as the standard is
concerned, but I'm not an expert.
This PR implements a part of WG14 N2653:
- Define C23 char8_t
- Define C11 char16_t
- Define C11 char32_t
Missing goals are:
- The type of UTF-8 character literals is changed from unsigned char to
char8_t. (Since UTF-8 character literals already have type unsigned
char, this is not a semantic change).
- New mbrtoc8() and c8rtomb() functions declared in <uchar.h> enable
conversions between multibyte characters and UTF-8.
- A new ATOMIC_CHAR8_T_LOCK_FREE macro.
- A new atomic_char8_t typedef name.
The epoll_wait functions need the rest of the epoll functions (create,
ctl) to be available to actually test them, as well as pipe to create a
usable file descriptor. This patch adds epoll_create, epoll_create1,
epoll_ctl, and pipe. These have tests, and the tests for epoll_wait,
epoll_pwait, and epoll_pwait2 (currently disabled) are updated to use
these newly available functions.
Now with the proxy header `hdr/math_macros.h`, the header
`include/llvm-libc-macros/math-macros.h` will not be included in overlay
mode, and the extra definitions for `__cplusplus` mode is not needed any
more.
Context: https://github.com/llvm/llvm-project/pull/87017
- Add proxy header `libc/hdr/math_macros.h` that will:
- include `<math.h>` in overlay mode,
- include `"include/llvm-libc-macros/math-macros.h"` in full build mode.
- Its corresponding CMake target `libc.hdr.math_macros` will only depend
on `libc.include.math` and `libc.include.llvm-libc-macros.math_macros`
in full build mode.
- Replace all `#include "include/llvm-libc-macros/math-macros.h"` with
`#include "hdr/math_macros.h"`.
- Add dependency to `libc.hdr.math_macros` CMake target when using
`add_fp_unittest`.
- Update the remaining dependency.
- Update bazel overlay: add `libc:hdr_math_macros` target, and replacing
all dependency on `libc:llvm_libc_macros_math_macros` with
`libc:hdr_math_macros`.
Summary:
This patch adds a temporary implementation that uses a struct-based
interface in lieu of varargs support. Once varargs support exists we
will move this implementation to the "real" printf implementation.
Conceptually, this patch has the client copy over its format string and
arguments to the server. The server will then scan the format string
searching for any specifiers that are actually a string. If it is a
string then we will send the pointer back to the server to tell it to
copy it back. This copied value will then replace the pointer when the
final formatting is done.
This will require a built-in extension to the varargs support to get
access to the underlying struct. The varargs used on the GPU will simply
be a struct wrapped in a varargs ABI.
The isfinite, isnan, and isinf "functions" are specified by C99..C23 to
be macros that act as type-generic functions. Defining them as their
__builtin_* counterparts works fine for this. However, in C++ the
identifiers need to be usable in different contexts, such as being
declared inside a C++ namespace. So define inline constexpr template
functions for them under `#ifdef __cplusplus`.
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).
