Implements chown and getgid per the POSIX specification and adds
corresponding unit tests. getgid is added as it is required by the chown
unit tests. This PR will address #165785
Co-authored-by: shubh@DOE <shubhp@mbm3a24.local>
Summary:
The changes in
43bd7e3bb9
altered how we handled including headers, this included the system on
the GPU target which poisoned the include path that was curated to not
include any system headers. Change this to only apply is the target OS
is Linux.
* Removes the copy-pasta implementation of wcstointeger,
and migrate the wcsto* family of functions to use a template
version of strtointeger.
* Fixes the out-of-bound read in the original implementation(s)
when the entire input string consists of whitespaces
(then the sign check can access OOB memory)
The code is currently slightly peppered with "if constexpr" statements
to distinguish between char and wchar_t. We can probably
simplify it in subsequent changes by:
* using overrides, so that internal::isalnum() is overriden for
both char and wchar_t (since C++ luckily allows us to reuse names).
* this wouldn't help for direct comparison with literals -
for this as a somewhat ugly workaround like is_char_literal(c, '0',
L'0')
`<wchar.h>` should at least include the forward declaration of `struct tm`,
since it's needed for the `wcsftime` declaration (also, see
https://man7.org/linux/man-pages/man0/wchar.h.0p.html).
Even though we don't yet have `wcsftime`, some downstream users (notably
- libcxx) expects to see `struct tm` declaration there, to re-declare it under
`std` namespace:
c46bfed1a4/libcxx/include/cwchar (L135)
So, add this type declaration to llvm-libc version of `wchar.h` now.
This makes the sorting behavior more uniform: functions and
macros are always sorted (separately), not only when merging.
This changes the sort order used for functions and other things
sorted by their symbol names. Symbols are sorted alphabetically
without regard to leading underscores, and then for identifiers
that differ only in the number of leading underscores, the fewer
underscores the earlier in the sort order. For the functions
declared in a generated header, adjacent names with and without
underscores will be grouped together without blank lines.
This is implemented by factoring the name field, equality, and
sorting support out of the various entity classes into a new
common superclass (hdrgen.Symbol).
This uncovered YAML's requirement to quote the string "NULL" to
avoid pyyaml parsing it as None (equivalent to Javascript null)
rather than a string.
This patch fixes a bug in strftime's return value when the formatted
output exactly fills the buffer, not including the null terminator. The
previous check failed to account for the null terminator in this case,
incorrectly returning the written count instead of 0.
This adds a few new features to hdrgen, all meant to facilitate
using it with inputs and outputs that are outside the llvm-libc
source tree.
The new `extra_standards` field is a dictionary to augment the
set of names that can be used in `standards` lists. The keys are
the identifiers used in YAML ("stdc") and the values are the
pretty names generated in the header comments ("Standard C").
This lets a libc project that's leveraging the llvm-libc sources
along with its own code define new APIs outside the formal and de
facto standards that llvm-libc draws its supported APIs from.
The new `license_text` field is a list of lines of license text
that replaces the standard LLVM license text used at the top of
each generated header. This lets other projects use hdrgen with
their own inputs to produce generated headers that are not tied
to the LLVM project.
Finally, for any function attributes that are not in a canonical
list known to be provided by __llvm-libc-common.h, an include
will be generated for "llvm-libc-macros/{attribute name}.h",
expecting that file to define the "attribute" name as a macro.
All this can be used immediately by builds that drive hdrgen and
build libc code outside the LLVM CMake build. Future changes
could add CMake plumbing to facilitate augmenting the LLVM CMake
build of libc with outside sources via overlays and cache files.
The JSON output support in hdrgen had a bug that tripped when
used with headers that use special-case headers like <stdint.h>
to supply some times, as well as llvm-libc-types/*.h headers.
This options sets a compile option when building sources inside the
string directory, and this option affects string_utils.h. But
string_utils.h is #included from more places than just the string
directory (such as from __support/CPP/string.h), leading to both
narrow-reads in those cases, but more seriously, ODR violations when the
two different string_length implementations are included int he same
program.
Having this option at the top level avoids this problem.
Relates to https://github.com/llvm/llvm-project/issues/119281
Note:
1) As this PR enables `-Werror` for `libc` tests, it's very likely some
downstream CI's may fail / start failing, so it's very likely this PR
may need to be reverted and re-applied.
P.S.
I do not have merge permissions, so I will need one of the reviews to
merge it for me. Thank you!
* Add FILE type declaration, as it should be presented in `<wchar.h>`,
as well as in `<stdio.h>`
* Fix argument type in `wcsrtombs` / `wcsnrtombs` function - it should
be restrict pointer to `mbstate_t`. Add restrict qualifier to internal
implementation as well.
This brings us closer to being able to build libcxx with wide-character
support against llvm-libc headers.
This PR adds required macro definitions to `<nl_types.h>` header, so
that they're available to the code including it.
The header itself was added in 12abe8aed6dc724546cf93c94d7ff6abe864f28b,
together with stub definitions of the three required functions.
Create a POSIX `<nl_types.h>` header with `catopen`, `catclose`, and
`catgets` function declarations.
Provide the stub/placeholder implementations which always return error.
This is consistent with the way
locales are currently (un-)implemented in llvm-libc.
Notably, providing `<nl_types.h>` fixes the last remaining issue with
building libc++ against llvm-libc
(on certain configuration of x86_64 Linux) after disabling threads and
wide-characters in libc++.
Based on the double precision's sin/cos fast path algorithm:
Step 1: Perform range reduction `y = x mod pi/8` with target errors <
2^-54.
This is because the worst case mod pi/8 for single precision is ~2^-31,
so to have up to 1 ULP errors from
the range reduction, the targeted errors should `be 2^(-31 - 23) =
2^-54`.
Step 2: Polynomial approximation
We use degree-5 and degree-4 polynomials to approximate sin and cos of
the reduced angle respectively.
Step 3: Combine the results using trig identities
```math
\begin{align*}
\sin(x) &= \sin(y) \cdot \cos(k \cdot \frac{\pi}{8}) + \cos(y) \cdot \sin(k \cdot \frac{\pi}{8}) \\
\cos(x) &= \cos(y) \cdot \cos(k \cdot \frac{\pi}{8}) - \sin(y) \cdot \sin(k \cdot \frac{\pi}{8})
\end{align*}
```
Overall errors: <= 3 ULPs for default rounding modes (tested
exhaustively).
Current limitation: large range reduction requires FMA instructions for
binary32. This restriction will be removed in the followup PR.
---------
Co-authored-by: Petr Hosek <phosek@google.com>
This patch adds the implementation for `inet_aton` function. Since this
function is not explicitly included in POSIX, I have marked it with
`llvm_libc_ext`. It is widely available and commonly used, and can also
be used to implement `inet_addr`, which is included in POSIX.
complex.yaml declares types cfloat16, cfloat128 and float128 in its
'types' section, causing the output complex.h to #include three headers
with names of the form "llvm-libc-types/cfloat16.h". But
include/CMakeLists.txt doesn't mention those types as dependencies in
the `add_header_macro` call for complex.h. As a result, cfloat16.h and
cfloat128.h are not installed by the 'install' target, but complex.h
still tries to to include them.
The third type header, float128.h, doesn't have this problem because the
`add_header_macro` math.h does mention it as a dependency. So I've added
all three headers as dependencies in complex.h, following the same
pattern, and now the install target installs the missing two headers.
This partially reverts #124200. Rather than using a CMake option to
control whether to enable `-fno-math-errno`, use LIBC_MATH_NO_ERRNO
configuration option. While there might be other cases when we want to
set `-fno-math-errno`, having LIBC_MATH_NO_ERRNO imply it should be
always safe and represents a reasonable starting point.
Reverts llvm/llvm-project#107540
This PR demonstrated improvements on micro-benchmarks but the gains did
not seem to materialize in production. We are reverting this change for
now to get more data. This PR might be reintegrated later once we're
more confident in its effects.
We can use UMAXV.4S to reduce the comparison result in a single
instruction. This improves performance by roughly 4% on Apple M1:
Summary
bin/libc.src.string.bcmp_benchmark3 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10 ran
1.01 ± 0.02 times faster than bin/libc.src.string.bcmp_benchmark3 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.01 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark3 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.01 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark3 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.01 ± 0.02 times faster than bin/libc.src.string.bcmp_benchmark2 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.02 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark2 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.03 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark2 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.03 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark2 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.05 ± 0.02 times faster than bin/libc.src.string.bcmp_benchmark1 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.05 ± 0.02 times faster than bin/libc.src.string.bcmp_benchmark1 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.05 ± 0.03 times faster than bin/libc.src.string.bcmp_benchmark1 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
1.05 ± 0.02 times faster than bin/libc.src.string.bcmp_benchmark1 --study-name="new bcmp" --sweep-mode --sweep-max-size=128 --output=/dev/null --num-trials=10
(1 = original, 2 = a variant of this patch that uses UMAXV.16B, 3 = this patch)
Reviewers: michaelrj-google, gchatelet, overmighty, SchrodingerZhu
Pull Request: https://github.com/llvm/llvm-project/pull/99260
Summary:
Without slab reclaiming this interface is much simpler and it can speed
up cases with a lot of churn. Basically, wastes memory for performance.
The VSCode instructions were stale from the transition to the runtimes
directory. This updates will all the options give on the Full Host Build
page.
Tested:
Built libc target.
