Fixes:
llvm-project/libc/test/integration/src/pthread/pthread_rwlock_test.cpp:59:29:
warning: missing field '__preference' initializer
[-Wmissing-field-initializers]
59 | pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER;
| ^
Also, add a test that demonstrates the same issue for
PTHREAD_MUTEX_INITIALIZER, and fix that, too.
PTHREAD_ONCE_INIT does not have this issue and does have test coverage.
Relying on features.h is problematic since codebases are free to have
such a header on their search path, which breaks compilation. libc
should instead provide a more standard way of getting __LLVM_LIBC__.
Since __llvm-libc-common.h is included from all libc headers, defining
__LLVM_LIBC__ there ensures that this define is available whenever any
of the standard header is included.
On some systems time_t is 32 bit, causing build errors (with -Werror)
in get_epoch which attempts to implicitly convert an int64_t to a
time_t.
Fixes:
error: implicit conversion loses integer precision: 'int64_t' (aka 'long
long') to 'time_t' (aka 'int') [-Werror,-Wshorten-64-to-32]
332 | return mktime_internal(timeptr);
| ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~
Follow up of #125168.
This patch adds endian-related macros to `endian.h`. We utilize compiler
built-ins for byte swap functions, which are already included in our
minimal supported compiler version.
In the process of adding strftime (#122556) I wrote this utility class
to simplify reading from a struct tm. It provides helper functions that
return basically everything needed by strftime. It's not tested
directly, but it is thoroughly exercised by the strftime tests.
For targets that have single precision FPU but not double precision FPU
such as Cortex M4, only using float-float in the intermediate
computations might reduce the code size compared to using double. In
this case, when the exact pass is skipped, the float-only option for
atan2f implemented in this PR reduces the code size of this function by
~1 KB compared to the double precision version.
One of these days, we'll be able to specify time to a computer...
Also, POSIX can remove stuff all they want. Folks probably will continue to
depend on broken interfaces forever.
Link: #124654
Link: https://austingroupbugs.net/view.php?id=1330
When cross compiling the libc-stdbit-tests, the existing tests trigger numerous
instances of -Wimplicit-int-conversion. The truncation of these implicit
promotions is intentional.
This was originally done for testing purposes, but after #126315 we now
do testing through GitHub Actions and should be instead using the
optimization setting chosen by the user.
Summary:
Currently we conditionally enable NVPTX lowering depending on the
language (C/C++/OpenMP). Unfortunately this causes problems because this
option is only present if the backend was enabled, which causes this to
error if you try to make LLVM-IR.
This patch instead makes it the only accepted lowering. The reason we
had it as opt-in before is because it is not handled by CUDA. So, this
pach also introduces diagnostics to prevent *all* creation of
device-side global constructors and destructors. We already did this for
variables, now we do it for attributes as well.
This inverts the responsibility of blocking this from the backend to the
langauage like it should be given that support for this is language
dependent.
This reverts commit bada9220b8.
Revert "[libc][stdfix] Implement fixed point `countlsfx` functions in llvm-libc (#125356)"
This reverts commit f2a1103b32.
`man 3 signal`'s declaration has a face _only a mother could love_.
sighandler_t and __sighandler_t are not defined in the C standard, or POSIX.
They are helpful typedefs provided by glibc and the Linux kernel UAPI headers
respectively since working with function pointers' syntax can be painful. But
we should not rely on them; in C++ we have `auto*` and `using` statements.
Remove the proxy header, and only include a typedef for sighandler_t when
targeting Linux, for compatibility with glibc.
Fixes: #125598
These warnings all come up in code modified by one of my two recent
commits c06d0ff806 and b53da77c50, 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.
