This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This one might be a bit controversial since the terminology has been
introduced from the start but I think `FRACTION_LEN` is a better name
here. AFAICT it really is "the number of bits after the decimal dot when
the number is in normal form."
`MANTISSA_WIDTH` is less precise as it's unclear whether we take the
leading bit into account.
This patch also renames most of the properties to use the `_LEN` suffix
and fixes useless casts or variables.
Internal builds of the unittests with msan flagged mempcpy_test.
==6862==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55e34d7d734a in length
llvm-project/libc/src/__support/CPP/string_view.h:41:11
#1 0x55e34d7d734a in string_view
llvm-project/libc/src/__support/CPP/string_view.h:71:24
#2 0x55e34d7d734a in
__llvm_libc_9999_0_0_git::testing::Test::testStrEq(char const*, char
const*, char const*, char const*,
__llvm_libc_9999_0_0_git::testing::internal::Location)
llvm-project/libc/test/UnitTest/LibcTest.cpp:284:13
#3 0x55e34d7d4e09 in LlvmLibcMempcpyTest_Simple::Run()
llvm-project/libc/test/src/string/mempcpy_test.cpp:20:3
#4 0x55e34d7d6dff in
__llvm_libc_9999_0_0_git::testing::Test::runTests(char const*)
llvm-project/libc/test/UnitTest/LibcTest.cpp:133:8
#5 0x55e34d7d86e0 in main
llvm-project/libc/test/UnitTest/LibcTestMain.cpp:21:10
SUMMARY: MemorySanitizer: use-of-uninitialized-value
llvm-project/libc/src/__support/CPP/string_view.h:41:11 in length
What's going on here is that mempcpy_test.cpp's Simple test is using
ASSERT_STREQ with a partially initialized char array. ASSERT_STREQ calls
Test::testStrEq which constructs a cpp:string_view. That constructor
calls the
private method cpp::string_view::length. When built with msan, the loop
is
transformed into multi-byte access, which then fails upon access.
I took a look at libc++'s __constexpr_strlen which just calls
__builtin_strlen(). Replacing the implementation of
cpp::string_view::length
with a call to __builtin_strlen() may still result in out of bounds
access when
the test is built with msan.
It's not safe to use ASSERT_STREQ with a partially initialized array.
Initialize the whole array so that the test passes.
When building with compiler-rt enabled, warnings such as the following
are
observed:
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/sys-stat-macros.h:46:9:
warning: 'S_IXOTH' macro redefined [-Wmacro-redefined]
#define S_IXOTH 00001
^
llvm-project/llvm/build/projects/compiler-rt/../libc/include/llvm-libc-macros/linux/fcntl-macros.h:61:9:
note: previous definition is here
#define S_IXOTH 01
^
It looks like we have these multiply defined. Deduplicate these flags;
users
should expect to find them in sys/stat.h. S_FIFO was wrong anyways
(should
have been S_IFIFO).
Also make type naming consistent by using `UIntType` instead of
`intU_t`.
This patch is a reland of #75196 but does not include the "use `FPBits`
instead of `FPBits_t`, `FPB`" part. This needs more work.
Reverts llvm/llvm-project#75196
GCC complains about change of meaning for `FPBits`
```
/home/llvm-libc-buildbot/buildbot-worker/libc-x86_64-debian-fullbuild/libc-x86_64-debian-gcc-fullbuild-dbg/llvm-project/libc/src/__support/FPUtil/generic/FMod.h:188:9: error: declaration of ‘using FPBits = struct __llvm_libc_18_0_0_git::fputil::FPBits<T>’ changes meaning of ‘FPBits’ [-fpermissive]
188 | using FPBits = FPBits<T>;
| ^~~~~~
```
I'll reland with a different name.
This patch fixes cmake configuration when building with
LLVM_LIBC_INCLUDE_SCUDO. In libc, LIBC_TARGET_ARCHITECTURE is renamed
from `riscv64` to `riscv`. However, `compiler-rt`, hence `scudo`,
distinguishes `riscv32` and `riscv64` in the support list. As a result,
we need to translate the architecture name accordingly.
If a function is declared with stack-protector, the compiler may try to
load the TLS. However, inside certain runtime functions, TLS may not be
available. This patch disables stack protectors for such routines to fix
the problem.
Closes#74487.
This patch sinks `EXPLICIT_BIT_MASK` into `get_explicit_mantissa` - the
only function using it. Then it sinks the content of
`FPCommonProperties` directly into `FPProperties`.
An unsigned integer was being initialized with -1 to set all its bits to
1, but this doesn't work for the BigInt class which may be used as an
integer type on systems that don't support uint128 natively. This patch
moves the initialization to use ~T(0) instead.
This is a follow up on #74481 that migrates code from all
specializations into `FPCommonProperties` (except for
`EXPLICIT_BIT_MASK` in the `X86_Binary80` specialization)
According to [wikipedia](https://en.wikipedia.org/wiki/Exponent_bias)
the "biased exponent" is the encoded form that is always positive
whereas the unbiased form is the actual "real" exponent that can be
positive or negative.
`FPBits` seems to be using `unbiased_exponent` to describe the encoded
form (unsigned). This patch simply use `biased` instead of `unbiased`.
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
