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
The generated asm for x86_64's longjmp has a function prolog and epilog.
The
epilog in particular is unreachable. Convert longjmp to a naked function
to
avoid these spurious instructions in longjmp.
Link: https://github.com/llvm/llvm-project/pull/112437/files#r1802085511
Hi there,
When building llvm-libc on the openEuler system, I encountered an issue
as shown in the image below:
This issue happens because the regular expression used in
`libc/cmake/modules/LLVMLibCArchitectures.cmake`: `string(REGEX MATCH
"Target: [-_a-z0-9.]+[ \r\n]+")` does not handle capital letters
properly in `openEuler`.
To fix this, I modified the regular expression to: `string(REGEX MATCH
"Target: [-_a-zA-Z0-9.]+[ \r\n]+")`. This change makes it compatible
with capital letters.
Fixes:
llvm-project/libc/src/setjmp/x86_64/setjmp.cpp:21:25: error: ‘int
__llvm_libc_19_0_0_git::setjmp(__jmp_buf*)’ specifies less restrictive
attribute than its target ‘int
__llvm_libc_19_0_0_git::__setjmp_impl__(__jmp_buf*)’: ‘nothrow’
[-Werror=missing-attributes]
21 | LLVM_LIBC_FUNCTION(int, setjmp, (__jmp_buf * buf)) {
| ^~~~~~
observed in the GCC build by manually expanding LLVM_LIBC_FUNCTION to add
`gnu::nothrow` to the alias.
We probably need to revisit adding nothrow throughout our declarations, so
there is probably a better way to clean this up in the future.
Link: #88054
Summary:
I'm going to attempt to move the `rpc.h` header to a separate folder
that we can install and include outside of `libc`. Before doing this I'm
going to try to trim up the file so there's not as many things I need to
copy to make it work. This dependency on `cpp::functional` is a low
hanging fruit. I only did it so that I could overload the argument of
the work function so that passing the id was optional in the lambda,
that's not a *huge* deal and it makes it more explicit I suppose.
Previously you could cast between bigints with different numbers of
bits, but only if they had the same underlying type. This patch adds the
ability to cast between bigints with different underlying types, which
is needed for #110894
This would consistently fail for me locally, to the point where I could not run
ninja libc-unit-tests without ninja libc_setjmp_unittests failing.
Turns out that since I enabled -ftrivial-auto-var-init=pattern in
commit 1d5c16d ("[libc] default enable -ftrivial-auto-var-init=pattern
(#78776)")
this has been a problem. Our x86_64 setjmp definition disabled -Wuninitialized,
so we wound up clobbering these registers and instead backing up
0xAAAAAAAAAAAAAAAA rather than the actual register value.
Use `naked` function attribute to avoid function prolog/epilog.
Fixes https://github.com/llvm/llvm-project/issues/110122
- Create remap_file_pages.h/.cpp wrapper for the linux sys call.
- Add UnitTests for remap_file_pages
- Add function to libc/spec/linux.td
- Add Function spec to mman.yaml
Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.
