Use LIBC_ERRNO_MODE_SYSTEM_INLINE instead as the default for the "public
packaging" (i.e. release mode) of an overlay build. The Bazel build has
already switched to use it by default in
5ccc734fa0355f971f8f515457a0bece33ab6642. This should be a safe change,
as LIBC_ERRNO_MODE_SYSTEM_INLINE works a drop-in (but simpler)
LIBC_ERRNO_MODE_SYSTEM replacement. Remove the associated code paths and
config settings.
Fixes issue #143454.
Part of https://github.com/llvm/llvm-project/issues/145349. Required to
allow `atexit` to work. As part of `HermeticTestUtils.cpp`, there is a
reference to `atexit()`, which eventually instantiates an instance of a
Mutex.
Instead of copying the implementation from
`libc/src/__support/threads/gpu/mutex.h`, we allow platforms to select
an implementation based on configurations, allowing the GPU and
single-threaded baremetal platforms to share an implementation. This can
be configured or overridden.
Later, when the threading API is more complete, we can add an option to
support multithreading (or set it as the default), but having
single-threading (in tandem) is in line with other libraries for
embedded devices.
Reverts llvm/llvm-project#146226
The MPFR test uses `mpfr_asinpi` which requires MPFR 4.2.0 or later, but
the Buildbots are running an older version of MPFR.
See https://lab.llvm.org/buildbot/#/builders/104/builds/27743 for
example.
I said I was going to revert the PR until we have a workaround for older
versions of MPFR, but then I forgot and I just disabled the entrypoints
which doesn't fix the Buildbot builds.
The function is implemented using the following Taylor series that's
generated using [python-sympy](https://www.sympy.org/en/index.html), and
it is very accurate for |x| $$\in [0, 0.5]$$ and has been verified using
Geogebra. The range reduction is used for the rest range (0.5, 1].
$$
\frac{\arcsin(x)}{\pi} \approx
\begin{aligned}[t]
& 0.318309886183791x \\
& + 0.0530516476972984x^3 \\
& + 0.0238732414637843x^5 \\
& + 0.0142102627760621x^7 \\
& + 0.00967087327815336x^9 \\
& + 0.00712127941391293x^{11} \\
& + 0.00552355646848375x^{13} \\
& + 0.00444514782463692x^{15} \\
& + 0.00367705242846804x^{17} \\
& + 0.00310721681820837x^{19} + O(x^{21})
\end{aligned}
$$
## Geogebra graph

Closes#132210
This PR fixes broken links in all files describing libc usage modes.
Please let me know if there are any other places that need updating.
---------
Co-authored-by: shubhp@perlmutter <shubhp@perlmutter.com>
Add `CLOCKS_PER_SEC` and the older `CLK_TCK`. Allows the user to define
a `__CLK_TCK` to override if necessary.
Also add an extra column for embedded AArch64 in `time.rst`
Main algorithm:
The Taylor series expansion of `asin(x)` is:
```math
\begin{align*}
asin(x) &= x + x^3 / 6 + 3x^5 / 40 + ... \\
&= x \cdot P(x^2) \\
&= x \cdot P(u) &\text{, where } u = x^2.
\end{align*}
```
For the fast path, we perform range reduction mod 1/64 and use degree-7
(minimax + Taylor) polynomials to approximate `P(x^2)`.
When `|x| >= 0.5`, we use the transformation:
```math
u = \frac{1 + x}{2}
```
and apply half-angle formula to reduce `asin(x)` to:
```math
\begin{align*}
asin(x) &= sign(x) \cdot \left( \frac{\pi}{2} - 2 \cdot asin(\sqrt{u}) \right) \\
&= sign(x) \cdot \left( \frac{\pi}{2} - 2 \cdot \sqrt{u} \cdot P(u) \right).
\end{align*}
```
Since `0.5 <= |x| <= 1`, `|u| <= 0.5`. So we can reuse the polynomial
evaluation of `P(u)` when `|x| < 0.5`.
For the accurate path, we redo the computations in 128-bit precision
with degree-15 (minimax + Taylor) polynomials to approximate `P(u)`.
This PR implements the following 8 functions along with the tests.
```c++
int idivr(fract, fract);
long int idivlr(long fract, long fract);
int idivk(accum, accum);
long int idivlk(long accum, long accum);
unsigned int idivur(unsigned fract, unsigned fract);
unsigned long int idivulr(unsigned long fract, unsigned long fract);
unsigned int idivuk(unsigned accum, unsigned accum);
unsigned long int idivulk(unsigned long accum, unsigned long accum);
```
ref: https://www.iso.org/standard/51126.htmlFixes#129125
---------
Signed-off-by: krishna2803 <kpandey81930@gmail.com>
Summary:
This patch moves the RPC server handling to be a header only utility
stored in the `shared/` directory. This is intended to be shared within
LLVM for the loaders and `offload/` handling.
Generally, this makes it easier to share code without weird
cross-project binaries being plucked out of the build system. It also
allows us to soon move the loader interface out of the `libc` project so
that we don't need to bootstrap those and can build them in LLVM.
Summary:
Currently we dispatch the writing mode off of a runtime enum passed in
by the constructor. This causes very unfortunate codegen for the GPU
targets where we get worst-case codegen because of the unused function
pointer for `sprintf`. Instead, this patch moves all of this to a
template so it can be masked out. This results in no dynamic stack and
uses 60 VGPRs instead of 117. It also compiles about 5x as fast.
The docs build action was failing with libc due to checks.rst not
existing in the expected path. This patch adjusts the path to the actual
path which seems to make everything happy. It seems like this did not
show up before as stdfix.rst was not included in a place that actually
caused it to get picked up by sphinx.
Move the hdrgen code under a subdirectory to treat it as a Python
module.
This mimics the structure used by llvm/utils/lit and
llvm/utils/mlgo-utils and simplifies integration of hdrgen to the build
system which rely on Python modules. In addition to that, it clarifies
which imports are coming from the hdrgen-specific helpers (e.g. "from
type import ..." becomes "from hdrgen.type import ...".
Leave the entrypoints (top-level main.py and yaml_to_classes.py) as-is:
they can keep being referred by the CMake build system w/o any changes.