Summary:
The `errno` variable is expected to be `thread_local` by the standard.
However, the GPU targets do not support `thread_local` and implementing
that would be a large endeavor. Because of that, we previously didn't
provide the `errno` symbol at all. However, to build some programs we at
least need to be able to link against `errno`. Many things that would
normally set `errno` completely ignore it currently (i.e. stdio) but
some programs still need to be able to link against correct C programs.
For this purpose this patch exports the `errno` symbol as a simple
global. Internally, this will be updated atomically so it's at least not
racy. Externally, this will be on the user. I've updated the
documentation to state as such. This is required to get `libc++` to
build.
Summary:
Straightforward RPC implementation of the `remove` function for the GPU.
Copies over the string and calls `remove` on it, passing the result
back. This is required for building some `libc++` functionality.
Summary:
I initially didn't report these as supported because they didn't provide
expected behavior and were very wasteful. The recent patch moved them to
a lock-free atomic implementation so they can now actually be used.
- Algorithm:
- Step 1 - Range reduction: for a double precision input `x`, return `k`
and `u` such that
- k is an integer
- u = x - k * pi / 128, and |u| < pi/256
- Step 2 - Calculate `sin(u)` and `cos(u)` in double-double using Taylor
polynomials with errors < 2^-70 with FMA or < 2^-66 w/o FMA.
- Step 3 - Calculate `sin(x) = sin(k*pi/128) * cos(u) + cos(k*pi/128) *
sin(u)` using look-up table for `sin(k*pi/128)` and `cos(k*pi/128)`.
- Step 4 - Use Ziv's rounding test to decide if the result is correctly
rounded.
- Step 4' - If the Ziv's rounding test failed, redo step 1-3 using
128-bit precision.
- Currently, without FMA instructions, the large range reduction only
works correctly for the default rounding mode (FE_TONEAREST).
- Provide `LIBC_MATH` flag so that users can set `LIBC_MATH =
LIBC_MATH_SKIP_ACCURATE_PASS` to build the `sin` function without step 4
and 4'.
Rather than propgating a compile define, add an explicit cmake flag for
controlling the size. The default for baremetal is 100KB and the default
for others is 1GB.
docgen now lists macro implementation status in the generated rst files.
Adds POSIX definition link property to docgen json API (`posix-definition`) and
changes the `defined` property of docgen json API to `c-definition`. Now that
docgen's api is getting more specified, adds validation checks to docgen to
start codifying the docgen api spec.
To make sure this all looks good, I've added POSIX definition links to signal.h
as a tester.
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.
Closes#84689.
Adding @lntue for review.
I was curious about the implementation of
`round_using_current_rounding_mode` used for the `nearbyint` functions.
It has one of the rounding modes as unreachable
([here](https://github.com/llvm/llvm-project/blob/main/libc/src/__support/FPUtil/NearestIntegerOperations.h#L243)),
and I was wondering if this was okay for the `nearbyint` functions.
---------
Co-authored-by: Michael Flanders <mkf727@cs.washington.edu>
Closes#88066.
Compared to before, the function names in the stdbit table are sorted by
function name, not order-of-appearance in the standard. Since macros
aren't printed by docgen.py and are still a TODO in the code, they are
also not printed in the new stdbit.h docs.
Adds some checks to docgen.py for conditions that tripped me up.
Add code to docgen.py to add the include of the `|check|` rewriter,
since all other generated files need it.
When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MUST match the ABI of the system being overlayed onto;
fullbuild more flexible (the only system ABI relevant is the OS kernel).
When implementing llvm-libc we generally prefer the include-what-you use
style of avoiding transitive dependencies (since that makes refactoring
headers more painful, and slows down build times). So what header do you
include for any given type or function declaration? For any given
userspace program, the answer is straightforward. But for llvm-libc
which is trying to support multiple ABIs (at least one per
configuration), the answer is perhaps less clear.
This proposal seeks to add one layer of indirection relative to what's
being done today.
It then converts users of sigset_t and struct epoll_event and the epoll
implemenations over to this convention as an example.
