Fix#74258
This is a reland of #74837, the error went unnoticed because it compiles
fine on
clang-16 but not on clang-12 which is the version used on the buildbots.
The fix was to explicitly initialize `BigInt` variables in `constexpr`
operations: `BigInt<Bits, Signed> result(0);` instead of `BigInt<Bits,
Signed> result;`
Not that I'm very good at SFINAE, but it seems that conversion operators
are
perhaps difficult to compose with SFINAE. I saw an example that used one
layer
of indirection to have an explicit return type that could then be used
with
enable_if_t.
Link: https://stackoverflow.com/a/7604580Fixes: #74623
GCC warns:
```
libc/src/__support/wctype_utils.h:33:20: error: comparison of unsigned
expression in ‘< 0’ is always false [-Werror=type-limits]
33 | if (c > 127 || c < 0)
| ~~^~~
```
Looking into the signedness of wint_t, it looks like depending on the
platform,
__WINT_TYPE__ is defined to int or unsigned int depending on the
platform.
Link:
https://lab.llvm.org/buildbot/#/builders/250/builds/14891/steps/6/logs/stdio
Implement `prctl` as specified in
https://man7.org/linux/man-pages/man2/prctl.2.html.
This patch also includes test cases covering two simple use cases:
1. `PR_GET_NAME/PR_SET_NAME`: where userspace data is passed via arg2.
2. `PR_GET_THP_DISABLE`: where return value is passed via syscal retval.
Following up the discussion at
https://github.com/llvm/llvm-project/pull/73469#discussion_r1409593911
by @nickdesaulniers.
According to FreeBSD implementation
(https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/upstream-freebsd/lib/libc/stdlib/hcreate.c),
`hsearch` is able to handle the cases where the global table is not
properly initialized. To do this, FreeBSD actually allows hash table to
be dynamically resized. If the global table is uninitialized at the
first call, the table will be initialized with a minimal size; hence
subsequent insertion will be reasonable as the table grows
automatically.
This patch mimic such behaviors. More precisely, this patch introduces:
1. a full table iterator that scans each element in the table,
2. a resize routine that is automatically triggered whenever the load
factor is reached where it iterates the old table and insert the entries
into a new one,
3. more tests that cover the growth of the table.
Summary:
The GPU tests tend to fail when run massively in parallel. This is why
we use a CMake job pool to limit it to 1 in most cases. We should
default to the configuration that is most likely to work, that being a
single thread. There aren't enough GPU tests for this to be a massive
increase in test time on the bots, so we should default to what works
guaranteed.
`ASSERT_EQ` requires that both operands have the same type but on arm32
`size_t` is `unsigned int` instead of `unsigned long`. Using `size_t`
explicitely to avoid "conflicting types for parameter 'ValType"
According to https://lab.llvm.org/buildbot/#/builders/163/builds/48002,
the generic build on HashTable fails with two major issues with
`werror`:
1. warnings on `error: suggest braces around initialization of
subobject`.
2. `__support/HashTable` tests are built regardless of its entrypoints`
This PR attempts to fix such issues.
Fixes:
libc/src/__support/float_to_string.h:551:48: error: conversion from
‘long
unsigned int’ to ‘int32_t’ {aka ‘int’} may change value
[-Werror=conversion]
551 | const int32_t shift_amount = SHIFT_CONST + (-exponent - IDX_SIZE *
idx);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Observed in gcc fullbuilds.
IDX_SIZE is a size_t (aka 'long unsigned int'), but has the value 128,
so the
expression is undergoing implicit promotion.
Link: https://lab.llvm.org/buildbot/#/builders/250/builds/14891
The test cases of mincore require getting correct page size from OS. As
`sysconf` is not functioning correctly, these patches are implemented in
a somewhat confusing way. We revert such patches and will reintroduce
mincore after we correct sysconf.
This reverts 54878b8, 985c0d1 and 418a3a4.
This reverts commit 606653091d1a66d1a83a1bfdea2883cc8d46687e.
Post submit buildbots are now red. We can use these explicit errors to better
clean up existing warnings, then reland this.
Link: #73966
A recent commit introduced warnings observable when building unit tests.
If the
unit tests don't fail when warnings are introduced into the build, then
we
might fail to notice them in the stream of output from check-libc.
Link: https://github.com/llvm/llvm-project/pull/72763/files#r1410932348
The [standard](https://eel.is/c++draft/expr.add#4.3) forbids forming
pointers to invalid objects even if the pointer is never read from or
written to. This patch makes sure that we don't do pointer arithmetic on
invalid pointers.
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
Summary:
This pointer has been causing issues. Allocating and reading from coarse
memory on the CPU is not guaranteed and varies depending on the kernel
version and support. Previously we attempted to pin the memory but this
caused unexpected failures. This should be a legal operation and work
around the problem as fine-grained memory should be always legal to
write to by both sides.
Summary:
This caused the bots to begin failing. Revert for now to get the bot
green.
This reverts commit 8bea804923a1b028e86b177caccb3258708ca01c.
This reverts commit e1395c7bdbe74b632ba7fbd90e2be2b4d82ee09e.
Summary:
This may be problematic to pin a stack pointer. Allocate it via the OS
allocator instead as the documentation suggests.
For some reason, if you attempt to free this pointer after the memory
region has been unlocked, it will return an invalid pointer.
Following from https://github.com/llvm/llvm-project/pull/73372:
Fuchsia targets currently don't support `float128`. Add detection for
`LIBC_TARGET_OS_IS_FUCHSIA`, and exclude this OS from setting
`LIBC_COMPILER_HAS_FLOAT128_EXTENSION`.
Summary:
Previously, we determined that coarse grained memory cannot be used in
the general case. That removed the buffer used to transfer the memory,
however we still had this lookup. Though we do not access the symbol
directly, it still conflicts with the agents apparently. Pin this as
well.
This resolves the problems @lntue was having with the `libc` GPU build.
A typo was leading to getc_unlocked.cpp.o being included into libc.a
twice.
I only noticed because I was trying to convert libc.a to a shared object
via
$ ld.lld -o libc.so --whole-archive libc.a
which errored since getc_unlocked was being defined twice.
Summary:
This portion of code handles mapping the RPC client memory over to the
device. HSA copies need to be between two slices of memory that HSA has
allocated. Previously we used coarse-grained memory to act as the host
source. However, the support for this varies depending on the kernel and
version and should not be relied upon. This patch changes that handling
to use the `hsa_amd_memory_lock` API to explicitly pin memory to a
location sufficient for a DMA transfer to the GPU.
C++20 will automatically generate an operator== with reversed operand
order, which is ambiguous with the written operator== when one argument
is marked const and the other isn't.
This operator currently triggers -Wambiguous-reversed-operator at
several usage sites in libc/test/src/__support/CPP/bitset_test.cpp,
starting with line 153.
Summary:
For reasons unknown to me, this function is undefined only on the GPU
build if you use `uintptr_t` but not `uint64_t` directly. This patch
makes an ifdef to use this directly for the GPU build to fix the bots.
There are some basic vectorization features in standard architecture
specifications. Such as SSE/SSE2 for x86-64, or NEON for aarch64. Even
though such features are almost always available, we still need some
methods to test fallback routines without any vectorization.
Previous attempt in hsearch adds a DISABLE_SSE2_OPT flag that tries to
compile the code with -mno-sse2 in order to test specific table scanning
routines. However, it turns out that such flag may have some unwanted
side effects hindering portability.
This PR introduces PREFER_GENERIC as an alternative. When a target is
built with PREFER_GENERIC, cmake will define a macro
__LIBC_PREFER_GENERIC such that developers can selectively choose the
fallback routine based on the macro.
This patch implements `hcreate(_r)/hsearch(_r)/hdestroy(_r)` as
specified in https://man7.org/linux/man-pages/man3/hsearch.3.html.
Notice that `neon/asimd` extension is not yet added in this patch.
- The implementation is largely simplified from rust's
[`hashbrown`](https://github.com/rust-lang/hashbrown/blob/master/src/raw/mod.rs)
as we only consider fix-sized insertion-only hashtables. Technical
details are provided in code comments.
- This patch also contains a portable string hash function, which is
derived from [`aHash`](https://github.com/tkaitchuck/aHash)'s fallback
routine. Not using any SIMD acceleration, it has a good enough quality
(passing all SMHasher tests) and is not too bad in speed.
- Some general functionalities are added, such as `memory_size`,
`offset_to`(alignment), `next_power_of_two`, `is_power_of_two`.
`ctz/clz` are extended to support shorter integers.
Previously the nextafter and nexttoward implementations were almost
identical, with the exception of whether or not the second argument was
a template or just long double. This patch unifies them by making the
two argument templates independent.
Some of the files in the docs/ directory are from 2019 and haven't been
updated since. This patch updates implementation_standard.rst,
source_tree_layout.rst, and has some minor fixes for strings.rst. It
also marks the most severely out of date files with a warning. These
files will be updated in a later patch.
