| Age | Commit message (Collapse) | Author |
|---|
|
The test added by #150802 was missing a close at the end.
|
|
Fix using wrong variable due to copy/paste error.
---------
Co-authored-by: codefaber <codefaber>
|
|
stdio test suite. (#149740)
|
|
|
|
|
|
|
|
https://github.com/llvm/llvm-project/issues/60481
|
|
This patch enables most of the libc entrypoints for riscv, except for fstatvfs, statvfs, dmull and fmull which are currently failing compilation. float16 is also not added, as rv32 doesn't seem to support it yet.
This patch also fixes the call to seek, which should take an off_t, and was missed in PR #68269.
|
|
This patch includes changes related to the use of off_t in libc,
targeted at 32-bit systems: in several places, the offset is used either
as a long or an off_t (64-bit signed int), but in 32-bit systems a long
type is only 32 bits long.
Fix a warning in mmap where a long offset is expected, but we were
passing an off_t. A static_cast and a comment were added to explain
that we know we are ignoring the upper 32-bit of the off_t in 32-bit
systems.
The code in pread and pwrite was slightly improved to remove a
#ifdef LIBC_TARGET_ARCH_IS_RISCV32; we are using an if constexpr now.
The Linux file operations were changed to use off_t instead of a long
where applicable. No changes were made to the standard API, e.g.,
ftell returns the offset as an int so we added a static_cast and a
comment explaining that this will cause a loss of integer precision
in 32-bit systems.
|
|
Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary changes
here.
This patch completely reworks how the GPU build is built and targeted.
Previously, we used a standard runtimes build and handled both NVPTX and
AMDGPU in a single build via multi-targeting. This added a lot of
divergence in the build system and prevented us from doing various
things like building for the CPU / GPU at the same time, or exporting
the startup libraries or running tests without a full rebuild.
The new appraoch is to handle the GPU builds as strict cross-compiling
runtimes. The first step required
https://github.com/llvm/llvm-project/pull/81557 to allow the `LIBC`
target to build for the GPU without touching the other targets. This
means that the GPU uses all the same handling as the other builds in
`libc`.
The new expected way to build the GPU libc is with
`LLVM_LIBC_RUNTIME_TARGETS=amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`.
The second step was reworking how we generated the embedded GPU library
by moving it into the library install step. Where we previously had one
`libcgpu.a` we now have `libcgpu-amdgpu.a` and `libcgpu-nvptx.a`. This
patch includes the necessary clang / OpenMP changes to make that not
break the bots when this lands.
We unfortunately still require that the NVPTX target has an `internal`
target for tests. This is because the NVPTX target needs to do LTO for
the provided version (The offloading toolchain can handle it) but cannot
use it for the native toolchain which is used for making tests.
This approach is vastly superior in every way, allowing us to treat the
GPU as a standard cross-compiling target. We can now install the GPU
utilities to do things like use the offload tests and other fun things.
Some certain utilities need to be built with
`--target=${LLVM_HOST_TRIPLE}` as well. I think this is a fine
workaround as we
will always assume that the GPU `libc` is a cross-build with a
functioning host.
Depends on https://github.com/llvm/llvm-project/pull/81557
|
|
This is step 4 of
https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
|
|
This is done so that tests which only require platform file but not the
platform streams can be run as unit tests. The tests which use platform
streams can only be hermetic tests to avoid conflicts with the
system-libc streams.
Fixes:
https://github.com/llvm/llvm-project/issues/64663
https://github.com/llvm/llvm-project/issues/63558
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D158193
|
|
Before this change, a separate static method named cleanup was used to
cleanup the file. Instead, now the close method cleans up the full file
object using the platform's close function.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D153377
|
|
The libc flush operation is not supposed to trigger a platform level
flush operation. See "Notes" on this Linux man page:
https://man7.org/linux/man-pages/man3/fflush.3.html
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D153182
|
|
This is a follow up to https://reviews.llvm.org/D152503
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D152533
|
|
The libc's equivalent of std::expected has a non-standard and
non-explicit operator T - https://github.com/llvm/llvm-project/issues/62738
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D152270
|
|
The previous patches added the necessary support for global constructors
used to register tests. This patch enables the AMDGPU target to build
and run the unit tests on the GPU. Currently this only tests the `ctype`
tests, but adding more should be straightforward from here on.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149517
|
|
This patch updates the `__support` unit tests to be built as hermetic
tests. The only tests we needed to disable were because of the use of
`realloc` which is not implemented correctly as it doesn't copy the
memory.
Depends on D149745
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D149750
|
|
This part of the effort to make all test related pieces into the `test`
directory. This helps is excluding test related pieces in a straight
forward manner if LLVM_INCLUDE_TESTS is OFF. Future patches will also move
the MPFR wrapper and testutils into the 'test' directory.
|
|
The File API has been refactored to allow cleanup using operator delete.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D140574
|
|
Few uses of free have not yet been replaced by the custom operator
delete yet. They will be done in a follow up patch.
Reviewed By: lntue, michaelrj
Differential Revision: https://reviews.llvm.org/D140526
|
|
Now errno is only set by the terminal entrypoints, and not the internal
implementations. This patch is part of the larger effort to not set
errno in libc internal code: https://github.com/llvm/llvm-project/issues/59278
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D139576
|
|
Reviewed By: michaelrj, lntue
Differential Revision: https://reviews.llvm.org/D137395
|
|
Previously, any line buffered write of size 0 would cause an error.
The variable used to track the index of the last newline started at
the size of the write - 1, which underflowed. Now it's handled properly,
and a test has been added to prevent regressions.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D127914
|
|
Previously all FILE objects were fully buffered, this patch adds line
buffering and unbuffered output, as well as applying them to stdout and
stderr.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D126829
|
|
Add FLAGS option for add_header_library, add_object_library,
add_entrypoint_object, and add_libc_unittest.
In general, a flag is a string provided for supported functions under the
multi-valued option `FLAGS`. It should be one of the following forms:
FLAG_NAME
FLAG_NAME__NO
FLAG_NAME__ONLY
A target will inherit all the flags of its upstream dependency.
When we create a target `TARGET_NAME` with a flag using (add_header_library,
add_object_library, ...), its behavior will depend on the flag form as follow:
- FLAG_NAME: The following 2 targets will be generated:
`TARGET_NAME` that has `FLAG_NAME` in its `FLAGS` property.
`TARGET_NAME.__NO_FLAG_NAME` that depends on `DEP.__NO_FLAG_NAME` if
`TARGET_NAME` depends on `DEP` and `DEP` has `FLAG_NAME` in its `FLAGS`
property.
- FLAG_NAME__ONLY: Only generate 1 target `TARGET_NAME` that has `FLAG_NAME`
in its `FLAGS` property.
- FLAG_NAME__NO: Only generate 1 target `TARGET_NAME.__NO_FLAG_NAME` that
depends on `DEP.__NO_FLAG_NAME` if `DEP` is in its DEPENDS list and `DEP`
has `FLAG_NAME` in its `FLAGS` property.
To show all the targets generated, pass SHOW_INTERMEDIATE_OBJECTS=ON to cmake.
To show all the targets' dependency and flags, pass
`SHOW_INTERMEDIATE_OBJECTS=DEPS` to cmake.
To completely disable a flag FLAG_NAME expansion, set the variable
`SKIP_FLAG_EXPANSION_FLAG_NAME=TRUE`.
Reviewed By: michaelrj, sivachandra
Differential Revision: https://reviews.llvm.org/D125174
|
|
They are added as entrypoint object targets. The header-gen
infrastructure has been extended to enable handling standard required
global objects. The libc-api-test has also been extended to verify the
global object declarations.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D126329
|
|
This is needed to prepare for adding FLAGS option.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D125055
|
|
The main code for the FILE struct is only enabled on platforms that it
works on, but before this patch the tests were included unconditionally.
Reviewed By: sivachandra, lntue
Differential Revision: https://reviews.llvm.org/D122363
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D122284
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D121976
|
|
This is now possible because we have a platform independent abstraction
for mutexes.
Reviewed By: lntue, michaelrj
Differential Revision: https://reviews.llvm.org/D121773
|
|
With modern architectures having a thread pointer and language supporting
thread locals, there is no reason to use a function intermediary to access
the thread local errno value.
The entrypoint corresponding to errno has been replaced with an object
library as there is no formal entrypoint for errno anymore.
Reviewed By: jeffbailey, michaelrj
Differential Revision: https://reviews.llvm.org/D120920
|
|
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D119458
|
