| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Split from #91572
---------
Co-authored-by: Nick Desaulniers (paternity leave) <nickdesaulniers@users.noreply.github.com>
|
|
rounding modes. (#96719)
Sharing the same algorithm as double precision sin:
https://github.com/llvm/llvm-project/pull/95736 and cos:
https://github.com/llvm/llvm-project/pull/96591
|
|
python script uses yaml and classes to generate c headers
header.py is only the main class file, the rest will be in another pr
more files to be added in multiple prs
|
|
Summary:
These warnings mean that it will lower to a libcall. Previously we just
disabled it locally, which didn't work with GCC. This patch does it
globally in the compiler options if the compiler is clang.
|
|
PR for adding microbenchmarking infrastructure for NVPTX. `nvlink`
cannot perform LTO, so we cannot inline `libc` functions and this
function call overhead is not adjusted for during microbenchmarking.
|
|
Added a class representation of a libc header file, allowing for easier
conversion from YAML to .h file output.
Classes include:
- Function (representing function headers)
- Include (representing various include statements found on a header
file)
- Macro (representing macro definitions)
- Enumeration (representing enum definitions)
- Type (representing include statements for NamedTypes)
- Object (representing ObjectSpec defintitions)
|
|
|
|
(#96325)
Fixes #95570
|
|
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.
|
|
Summary:
This function uses atomics now, which emit warnings on some platforms
that don't support full lock-free atomics. These aren't specifically
wrong, and in the future we could investigate a libc configuration
specialized for single-threaded microprocessors, but for now we should
get the bot running again.
|
|
Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every target supports TLS, and
even more do not support non-zero initializers on TLS.
The C standard states that the `rand()` function need not be thread,
safe. However, many implementations provide thread-safety anyway.
There's some confusing language in the 'rationale' section of
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html,
but given that `glibc` uses a lock, I think we should make this thread
safe as well. it mentions that threaded behavior is desirable and can be
done in the two ways:
1. A single per-process sequence of pseudo-random numbers that is shared
by all threads that call rand()
2. A different sequence of pseudo-random numbers for each thread that
calls rand()
The current implementation is (2.) and this patch moves it to (1.). This
is beneficial for the GPU case and more generic support. The downside is
that it's slightly slower to do these atomic operations, the fast path
will be two atomic reads and an atomic write.
|
|
|
|
The opaque type jmp_buf should only be tested in fullbuild mode.
|
|
rounding modes. (#96591)
Sharing the same algorithm as double precision sin:
https://github.com/llvm/llvm-project/pull/95736
|
|
|
|
r7 is reserved in thumb2 (typically for the frame pointer, as opposed to r11 in
ARM mode), so assigning to a variable with explicit register storage in r7 will
produce an error.
But r7 is where the Linux kernel expects the syscall number to be placed. We
can use a temporary to get the register allocator to pick a temporary, which we
save+restore the previous value of r7 in.
Fixes: #93738
|
|
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#6212stack-constraints-at-a-public-interface
mentions that the stack on ARM32 is double word aligned.
Remove confused comments around ArgcType. argc is always an int, passed on the
stack, so we need to store a pointer to it (regardless of ILP32 or LP64).
|
|
Part of #93566.
|
|
Summary:
This patch adds `CMAKE_REQUIRED_FLAGS` for the GPU build so checks like
`check_cxx_compiler_flags` work as expected. This is required because we
need to hack around the potential lack of `nvlink` and `ptxas` for NVPTX
targets and the fact that the AMDGPU target needs `-nogpulib` to avoid
errors on lack of ROCm. This makes a few of the checks pass and also
allows us to just check `-mcpu=native` for architecture detection
instead of finding the tools manually.
|
|
Summary:
This test fails due to alignment issues, it's likely that it's
misaligned on other targets too and they just don't crash on it.
@PiJoules maybe we should run this with ubsan?
|
|
rounding modes. (#95736)
- 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'.
|
|
This is necessary for 32b platforms such as ARM and i386.
Link: #94128
|
|
Necessary for arm32 cross full build.
|
|
conditional. (#96373)
|
|
baremetal. (#96372)
Downstream build issue reported:
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8744479865106393873/overview
|
|
We only need to set `--target=` for LLD when cross compiling. This should fix
the host build using BFD or targeting the host.
Fixes: #96342
|
|
|
|
Otherwise the startup objects will fail to link since they were cross compiled,
but the linker is not informed of the intent to cross compile, which results in
linker errors when the host architecture does not match the target
architecture.
|
|
This reverts commit f333fc5c9732a5b64ae0bca09ade6f0036e80c40.
Accidentally pushed, sorry!
|
|
|
|
Function header files for epoll_pwait and epoll_pwait2 have const
modifier on
SigSetPtrType in function signature, but the linux.td file does not
reflect that.
.td file located in libc/spec/linux.td
epoll functions located in libc/src/sys/epoll
|
|
Part of #93566.
|
|
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.
|
|
|
|
|
|
functions (#95159)
Part of #93566.
|
|
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).
|
|
Non-root users may be able to set real-time scheduling policies. Don't
expect failure to set real-time scheduling policies based on UID.
Instead, check that if it fails, it is either due to missing privileges,
or unsupported parameters if the scheduling policy is not mandated by
POSIX.
Fixes #95564.
|
|
Fixes:
llvm-project/libc/src/__support/OSUtil/linux/fcntl.cpp:63:26: error:
implicit conversion loses integer precision: '__off64_t' (aka 'long
long')
to '__off_t' (aka 'long') [-Werror,-Wshorten-64-to-32]
flk->l_start = flk64.l_start;
~ ~~~~~~^~~~~~~
llvm-project/libc/src/__support/OSUtil/linux/fcntl.cpp:64:24: error:
implicit conversion loses integer precision: '__off64_t' (aka 'long
long')
to '__off_t' (aka 'long') [-Werror,-Wshorten-64-to-32]
flk->l_len = flk64.l_len;
~ ~~~~~~^~~~~
We already have an overflow check, just need the cast to be explicit.
This
warning was observed on the 32b ARM build in overlay mode.
|
|
Fixes https://github.com/llvm/llvm-project/issues/95638
The check was `if(unsigned_num >= 0)` which will always be true. The
intent was to check for zero, but the `for` loop inside the `if` was
already doing that.
|
|
|
|
|
|
malloc in overlay mode. (#95845)
This causes an issue in overlay mode:
https://github.com/llvm/llvm-project/pull/95736#issuecomment-2172739705
|
|
Summary:
Not all platforms support this function or header, but it was being
included by every test. Move it inside of the `ifdef` for the only user,
which is aarch64.
|
|
|
|
Fixes #93711 .
This patch implements the ``fdopen`` function. Given that ``fdopen``
internally calls ``fcntl``, the implementation of ``fcntl`` has been
moved to the ``__support/OSUtil``, where it serves as an internal public
function.
|
|
(#95619)
This reverts commit eca988aa4420f33810f9830c80ff9f149b7928ff. The
underlying libc issue was fixed by PR#95576.
The original PR is #95436 , which adds printf, putchar and vprintf in
bareemetal entrypoints
|
|
|
|
Bitfield conversion problem tested at: https://godbolt.org/z/dxjhs5Ghr
|
|
|
