The previous implementation of the ctype functions assumed ASCII.
This patch changes to a switch/case implementation that looks odd, but
actually is easier for the compiler to understand and optimize.
Thanks to the effort of @RoseZhang03 and @aaryanshukla under the
guidance of
@michaelrj-google and @amykhuang, we now have newhdrgen and no longer
have a
dependency on TableGen and thus LLVM in order to start bootstrapping a
full
build.
This PR removes:
- LIBC_HDRGEN_EXE; the in tree newhdrgen is the only hdrgen that can be
used.
- LIBC_USE_NEW_HEADER_GEN; newhdrgen is the default and only option.
- LIBC_HDRGEN_ONLY; there is no need to have a distinct build step for
old
hdrgen.
- libc-api-test and libc-api-test-tidy build targets.
- Deletes all .td files.
It does not rename newhdrgen to just hdrgen. Will follow up with a
distinct PR
for that.
Link: #117209
Link: #117254Fixes: #117208
`timespec_get` is C standard counterpart to POSIX `clock_gettime`. On
Linux we simply use `clock_gettime`. On baremetal we introduce a new
external API `__llvm_libc_timespec_get_utc` that should be implemented
by the vendor.
This PR implements process_mrelease.
A previous PR was merged #117503, but failed on merge due to an issue in
the tests. Namely the failing tests were comparing against return type
as opposed to errno. This is fixed in this PR.
Summary:
The AMDGPU backend can handle wavefront sizes of 32 and 64, with the
native hardware preferring one or the other. The user can override the
hardware with `-mwavefrontsize64` or `-mwavefrontsize32` which
previously wasn't handled. We need to know the wavefront size to know
how much memory to allocate and how to index the RPC buffer. There isn't
a good way to do this with ROCm so we just use the LLVM support for
offloading to check this from the image.
- migrate more `-O3` to `${libc_opt_high_flag}`
- workaround a issue with `LLP64` in test. The overflow testing is
guarded by a constexpr but the literal overflow itself will still
trigger warnings.
Notice that for math smoke test, for some reasons, the
`${libc_opt_high_flag}` will be passed into `lld-link` which confuses
the linker so there are still some warnings leftover there. I can
investigate more when I have time.
Summary:
Previous patches have made the `rpc.h` header independent of the `libc`
internals. This allows us to include it directly rather than providing
an indirect C API. This patch only does the work to move the header. A
future patch will pull out the `rpc_server` interface and simply replace
it with a single function that handles the opcodes.
This reverts commit 93b83642ee34d0092b94776728dad0117c2b72a1.
- Correct riscv32 assumption about alignment (bit of a hack).
- Fix test case where the largest_small and smallest sizes are the
same.
- Fix assertion expressions.
- Fix incorrect small size in freestore_test.
- There may only be one small size for high alignment and small
pointers (riscv32).
- Don't rely on stack alignment in FreeList test.
This reworks the free store implementation in libc's malloc to use a
dlmalloc-style binary trie of circularly linked FIFO free lists. This
data structure can be maintained in logarithmic time, but it still
permits a relatively small implementation compared to other
logarithmic-time ordered maps.
The implementation doesn't do the various bitwise tricks or
optimizations used in actual dlmalloc; it instead optimizes for
(relative) readability and minimum code size. Specific optimization can
be added as necessary given future profiling.
After #115084 the 80 bit long double tests error if sizeof(long double)
isn't 96 or 128 bits. This caused failures in long double is double
systems (since long double is 64 bits) so I've disabled the 80 bit long
double tests on systems that don't use them.
`long double` is haunted on most architectures, but it is especially so on
i386-linux-gnu. While have 80b of significant data, on i386-linux-gnu this type
has 96b of storage.
Fixes for supporting printf family of conversions for `long double` on
i386-linux-gnu. This allows the libc-stdlib-tests and libc_stdio_unittests
ninja target tests to pass on i386-linux-gnu.
Fixes: #110894
Link: #93709
Co-authored-by: Michael Jones <michaelrj@google.com>
I normally run my cmake with LIBC_CMAKE_VERBOSE_LOGGING set to ON so I
can debug build issues more easily. One of the effects of this is I see
which tests/entrypoints are skipped on my machine. This patch fixes up
the tests and entrypoints that were skipped, but easily fixed. These
were:
libc.src.pthread.pthread_spin_destroy
libc.src.pthread.pthread_spin_init
libc.src.pthread.pthread_spin_lock
libc.src.pthread.pthread_spin_trylock
libc.src.pthread.pthread_spin_unlock
(entrypoints were just missing)
libc.src.wchar.btowc
(I forgot to finish it)
libc.test.src.sys.statvfs.linux.statvfs_test
libc.test.src.sys.statvfs.linux.fstatvfs_test
(Incorrect includes for rmdir, needed some cleanup)
libc.test.integration.src.unistd.execve_test
(wrong dep for errno)
libc.test.src.math.smoke.fmaf_test
(add_fp_unittest doesn't support flags)
libc.test.src.stdio.scanf_core.converter_test
(needed to be moved away from string_reader, further cleanup needed)
- Implementation of `tan` for 16-bit floating point inputs scaled by pi.
i.e,. `tanpif16()`
- Implementation of Tanpi in MPFRWrapper for MPFR versions < 4.2
- Exhaustive tests for `tanpif16()`
Hello, I merged this https://github.com/llvm/llvm-project/pull/114904 a
few mins ago and the tests failed because i did not add the header
`src/stdlib/_Exit.h` in `at_quick_exit_test.cpp` and `atexit_test.cpp`.
I ran both builds/tests and everything was good. thanks
Some tests were including LibcTest.h directly. Instead you should
include Test.h which does proper indirection for other test frameworks
we support (zxtest, gtest). Also added some license headers to tests
that were missing them.
I have commented out the test for `neg_zero`(creal) because :
1. real(neg_zero + 0.0i) equals zero.
2. real(neg_zero - 0.0i) equals neg_zero.
I am not sure if this is the intended behaviour.
[EDIT]
I have updated tests for `neg_zero` (creal) to be :
```
EXPECT_FP_EQ(func(CFPT(neg_zero - zero * 1.0i)), neg_zero);
EXPECT_FP_EQ(func(CFPT(neg_zero + zero * 1.0i)), zero);
```
because all three [gcc, clang and GNU MPC] also give the same result.
https://godbolt.org/z/hxhcn6aof
and it seems that it is indeed the correct behaviour since Imaginary
types are not supported yet, refer #113671
These are failing to link for some buildbots. It's not immediately clear
why,
disable these and add a todo to investigate.
Link: #111403
Link: #114566
Link: #114618
This avoids -Wmacro-redefinition diagnostics observed when building the
libc_include_tests ninja target.
For example, the signbit_test will attempt to include BOTH our math-macros.h
(via math-function-macros.h), and the system's math.h (via hdr/math_macros.h).
While it's nice that we can get some coverage of the headers we will provide to
end users of fullbuilds in CI of overlay builds, it's not worth chasing each
individual conflict and disabling some include tests as conflicts arise.
Disable the include tests unless `-DLLVM_LIBC_FULL_BUILD=ON` is specified.
We shouldn't be including headers directly from asm-generic for macros.
It's safer to get those through the correct primary header where
possible (e.g. fcntl instead of asm-generic/fcntl).
For our public headers we may need to include the asm-generic
headers instead of defining all the macros ourselves, but that's
something for a followup PR.
Previously shm_test was including <asm-generic/fcntl.h> for the macro
FD_CLOEXEC. This patch adds that macro to the list we have defined, and
redirects the test to use the correct proxy header.
`strrchr("foo", '\0')` is defined to point to the end of `foo`, rather
than returning NULL. This wasn't caught by tests, since llvm-libc's
`ASSERT_STREQ(nullptr, "");` is not an assertion error.
While I'm here, refactor the test slightly to check for NULL more
specifically. I considered adding fancier `ASSERT`s (and changing the
semantics of `ASSERT_STREQ`), but opted for a more local fix by fair
dice roll.
