These warnings all come up in code modified by one of my two recent
commits c06d0ff806b72b1 and b53da77c505a2d3, and all relate to implicit
integer type conversion. In a build of ours with strict compile options
two of them became errors. Even without that problem, it's worth fixing
them to reduce noise that might hide a more serious warning.
This is to ensure that calls to `setjmp(3)` result in correct code
generation that respects `setjmp(3)`'s `returns_twice` behavior.
Otherwise, we might run into bugs (for example, Clang may perform
tail-call optimization on this function if `-fno-builtins` is set
(#122840)).
---------
Co-authored-by: Nick Desaulniers <nick.desaulniers@gmail.com>
riscv32 specifically doesn't provide EITHER SYS_poll or SYS_ppoll. We may be
able to reimplement poll in terms of syscalls to SYS_ppoll_time64, but will
leave that as a TODO for the future. (Such as when we want to be able to cross
compile for riscv32).
Link: #125940Fixes: #125118
riscv32 currently doesn't have SYS_wait4, so wait4 is implemented via fallback
to SYS_waitid. In #125572, I missed that we had one use of the removed
__W_CONTINUED value. Hard code it here.
Fixes: #125572
This test was problematic, and also unnecessary. It's not really
a test of the libc functionality or ABI. That's already covered
by the LlvmLibcStackChkFail.Death test. The Smash test was in
fact just testing that the compiler produces the call in the
expected situation. That's a compiler test, not a libc test.
It's not really feasible to make a test like this both reliable
and safe. Since it's not something libc needs to test, it's not
worth trying.
Summary:
The CUDA impelementation has long supported the `width` argument on its
shuffle instrucitons, which makes it more difficult to replace those
uses with this helper. This patch just correctly implements that for
AMDGPU and NVPTX so it's equivalent to `__shfl_sync` in CUDA. This will
ease porting.
Fortunately these get optimized out correctly when passing in known
widths.
Previously this test was entirely disabled under asan, but not
hwasan. Instead of disabling the test, make the test compatible
with both asan and hwasan by disabling sanitizers only on the
subroutine that does the stack-smashing.
The existing options for bin→dec float conversion are all based on the
Ryū algorithm, which generates 9 output digits at a time using a table
lookup. For users who can't afford the space cost of the table, the
table-lookup subroutine is replaced with one that computes the needed
table entry on demand, but the algorithm is otherwise unmodified.
The performance problem with computing table entries on demand is that
now you need to calculate a power of 10 for each 9 digits you output.
But if you're calculating a custom power of 10 anyway, it's easier to
just compute one, and multiply the _whole_ mantissa by it.
This patch adds a header file alongside `float_dec_converter.h`, which
replaces the whole Ryū system instead of just the table-lookup routine,
implementing this alternative simpler algorithm. The result is accurate
enough to satisfy (minimally) the accuracy demands of IEEE 754-2019 even
in 128-bit long double. The new float128 test cases demonstrate this by
testing the cases closest to the 39-digit rounding boundary.
In my tests of generating 39 output digits (the maximum number supported
by this algorithm) this code is also both faster and smaller than the
USE_DYADIC_FLOAT version of the existing Ryū code.
When IntegerToString converts a BigInt into decimal, it determines each
digit by computing `n % 10` and then resets n to `n / 10`, until the
number becomes zero. The div and mod operations are done using
`BigInt::divide_unsigned`, which uses the simplest possible bit-by-bit
iteration, which is a slow algorithm in general, but especially so if
the divisor 10 must first be promoted to a BigInt the same size as the
dividend. The effect is to make each division take quadratic time, so
that the overall decimal conversion is cubic – and the division is
quadratic in the number of _bits_, so the constant of proportionality is
also large.
In this patch I've provided custom code to extract decimal digits much
faster, based on knowing that the divisor is always 10, and processing a
word at a time. So each digit extraction is linear-time with a much
smaller constant of proportionality.
Full comments are in the code. The general strategy is to do the
reduction mod 10 first to determine the output digit; then subtract it
off, so that what's left is guaranteed to be an exact multiple of 10;
and finally divide by 10 using modular-arithmetic techniques rather than
reciprocal-approximation-based ordinary integer division.
I didn't find any existing tests of IntegerToString on a BigInt, so I've
added one.
While GCC's -Wdeprecated is on by default and doesn't do much,
Clang's -Wdeprecated enables many more things. More apply in
C++20, so switch a test file that tickled one to using that. In
future, C++20 should probably be made the baseline for compiling
all the libc code.
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
Summary:
This introduces libc cache files and adds one for building the GPU
support. The cache files will set defaults for these arguments which can
be overridden if the user needs to. They also serve as documentation for
how the builid is expected to look.
[libc][docs] add cpio to documentation and include related functi…
These changes ensure that the cpio header is documented properly
with respect to the issue
(https://github.com/llvm/llvm-project/issues/122006 ).
**Changes:**
1. **cpio.yaml**: Created a new YAML file for cpio with functions
and related macros.
2. **CMakeLists.txt**: Added cpio to the documentation
directories.
3. **index.rst**: Included `cpio` in the documentation index.
---------
Co-authored-by: siya <siya@Siya.com>
Summary:
This is a blocker on another patch in the OpenMP runtime. The problem is
that NVIDIA truly doesn't handle RPC-based allocations very well. It
cannot reliably update the MMU while a kernel is running and it will
usually deadlock if called from a separate thread due to internal use of
TLS.
This patch just removes the definition of `malloc` and `free` for NVPTX.
The result here is that they will be undefined, which is the cue for the
`nvlink` linker to define them for us. So, as far as `libc` is concerned
it still implements malloc.
Update string_utils' string_length to work with char* or wchar_t*, so that it
may be reusable when implementing wmemchr, wcspbrk, wcsrchr, wcsstr.
Link: #121183
Link: #124027
Co-authored-by: Nick Desaulniers <ndesaulniers@google.com>
---------
Co-authored-by: Tristan Ross <tristan.ross@midstall.com>
Also, update the unit tests that were checking for SIGSEGV to not check for a
specific signal.
To further improve this check, it may be worth:
- renaming the configuration option/macro/docs to be clearer about intent.
- swap __builtin_trap for __builtin_unreachable, removing the preprocessor
variants of LIBC_CRASH_ON_NULLPTR, then unconditionally using
`-fsanitize=unreachable -fsanitize-trap=unreachable` in cmake flags when
LIBC_ADD_NULL_CHECKS is enabled.
- building with `-fno-delete-null-pointer-checks` when LIBC_ADD_NULL_CHECKS (or
when some larger yet to be added hardening config) is enabled.
Link: #111546
I found this out the hard way...though we don't suggest in our docs setting or
unsetting COMPILER_RT_BUILD_SANITIZERS, I had this explicitly disabled in a
cmake script I was using to setup an llvm-libc based sysroot. While the libc
compiled, hello world failed to link due to missing references to malloc at
link time. Though I had set the cmake variables to opt into using scudo,
apparently explicitly disabling sanitizers will still prevent scudo from being
built... Check for this at configure time and stop the build then.
Found while trying to consolidate our command line flags between tests and
underlying object files.
error: extra ';' after member function definition [-Werror,-Wextra-semi]
Link: #119281
