These are failing to link for some buildbots. It's not immediately clear
why,
disable these and add a todo to investigate.
Link: #111403
Link: #114566
Link: #114618
This avoids -Wmacro-redefinition diagnostics observed when building the
libc_include_tests ninja target.
For example, the signbit_test will attempt to include BOTH our math-macros.h
(via math-function-macros.h), and the system's math.h (via hdr/math_macros.h).
While it's nice that we can get some coverage of the headers we will provide to
end users of fullbuilds in CI of overlay builds, it's not worth chasing each
individual conflict and disabling some include tests as conflicts arise.
Disable the include tests unless `-DLLVM_LIBC_FULL_BUILD=ON` is specified.
We are finalizing the header inclusion policy, and for our public
headers in the `libc/include` folder, they must use relative path in
`"..."` when including each other.
This PR does the cleanup making sure that all the public header
inclusions in `libc/include` folder use relative paths.
---------
Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>
We shouldn't be including headers directly from asm-generic for macros.
It's safer to get those through the correct primary header where
possible (e.g. fcntl instead of asm-generic/fcntl).
For our public headers we may need to include the asm-generic
headers instead of defining all the macros ourselves, but that's
something for a followup PR.
Previously shm_test was including <asm-generic/fcntl.h> for the macro
FD_CLOEXEC. This patch adds that macro to the list we have defined, and
redirects the test to use the correct proxy header.
The proxy header definition for mode_t was using an incorrect form for
its dependency on fcntl_overlay. The relative paths for dependencies can
only go down, not up so "../" doesn't work. This patch fixes it to be
absolute.
`strrchr("foo", '\0')` is defined to point to the end of `foo`, rather
than returning NULL. This wasn't caught by tests, since llvm-libc's
`ASSERT_STREQ(nullptr, "");` is not an assertion error.
While I'm here, refactor the test slightly to check for NULL more
specifically. I considered adding fancier `ASSERT`s (and changing the
semantics of `ASSERT_STREQ`), but opted for a more local fix by fair
dice roll.
When running Bionic's testsuite over llvm-libc, tests broke because
e.g.,
```
const char *str = "abc";
char buf[7]{"111111"};
strlcpy(buf, str, 7);
ASSERT_EQ(buf, {'1', '1', '1', '\0', '\0', '\0', '\0'});
```
On my machine (Debian w/ glibc and clang-16), a `printf` loop over `buf`
gets unrolled into a series of const `printf` at compile-time:
```
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", 0);
printf("%d\n", '1');
printf("%d\n", '1');
printf("%d\n", 0);
```
Seems best to match existing precedent here.
In glibc and musl, fexcept_t is unsigned short int on x86 and
unsigned int on other machines that llvm-libc supports. Match
that ABI (only different from before on x86) and API (different
everywhere as it was previously signed).
MPFR functionality is provided by the MPFRWrapper instead, and the direct "mpfr.h" inclusion is not needed - this test doesn't rely on it (similar to its sibling libc/test/src/math/exhaustive/cospif_test.cpp that doesn't have it).
Implementation of `cos` for half precision floating point inputs scaled
by pi (i.e., `cospi`), correctly rounded for all rounding modes.
---------
Co-authored-by: OverMighty <its.overmighty@gmail.com>
This changes the entry-point Python script of newhdrgen to use
the idiomatic main() function of no arguments that does the whole
job of the script. This replaces the unusual pattern of having
an idiosyncratic main(...) signature and having the script's
direct code do argument parsing outside the main function. The
idiomatic pattern makes it possible to usefully wrap the script
in Python and still use its full command-line functionality.
It's checked in a cmake function that builds up a list called
`config_options`. But the check was appending to a list called
`compile_options`, so the intended `-DLIBC_MATH=whatever` didn't end up
on the actual compile command lines.
Don't use plain `if` for things that are compile-time constants.
Instead, use `if constexpr`. This both ensures that these are
properly wired up constant expressions as intended, and prevents
warnings from the compiler about useless `if` checks that look in
the source like they're meant to do something at runtime but will
just be compiled away.
When using `-mprefer-vector-width=128` with `-march=sandybridge` copying
3 cache lines in one go (192B) gets converted into `rep;movsb` which
translate into a 60% hit in performance.
Consecutive calls to `__builtin_memcpy_inline` (implementation behind
`builtin::Memcpy::block_offset`) are not coalesced by the compiler and
so calling it three times in a row generates the desired assembly. It
only differs in the interleaving of the loads and stores and does not
affect performance.
This is needed to reland
https://github.com/llvm/llvm-project/pull/108939.
For Hand-In-Hand we need float to string to support a wider set of
architectures, specifically the ones that libc++ supports. This includes
powerpc, which apparently uses "double double" as its long double type.
Since Hand-In-Hand isn't currently using long double, this just opts
them out.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
Scanf parsing reads the longest possibly valid prefix for a given
conversion. Then, it performs the conversion on that string. In the case
of "0xZ" with a hex conversion (either "%x" or "%i") the longest
possibly valid prefix is "0x", which makes it the "input item" (per the
standard). The sequence "0x" is not a "matching sequence" for a hex
conversion, meaning it results in a matching failure, and parsing ends.
This is because to know that there's no valid digit after "0x" it reads
the 'Z', but it can only put back one character (the 'Z') leaving it
with consuming an invalid sequence.
(inspired by a thread on the libc-coord mailing list:
https://www.openwall.com/lists/libc-coord/2024/10/15/1, see 7.32.6.2 in
the standard for more details.)
In IEEE 754 and C standards, when calling `frexp` with Inf/Nan inputs,
the exponent result is unspecified. In this case, FreeBSD libc and musl
just passthrough `exp`, while glibc, FreeBSD libm set exp = 0, and MSVC
set exp = -1.
By default, LLVM libc will passthrough `exp` just as FreeBSD libc and
musl, but we also allow users to explicitly choose the return exp value
in this case for compatibility with other libc.
Notice that, gcc did generate passthrough `exp` for `frexp(NaN/Inf,
exp)`: https://godbolt.org/z/sM8fEej4E
