Introduce Month enum.
Use designated initializers instead of comments to ensure that tm_data
is initialized correctly. Use Month enum for initializing .tm_mon to
avoid off-by-one errors.
Co-authored-by: Raman Tenneti <rtenneti@google.com>
Reviewed By: rtenneti
Differential Revision: https://reviews.llvm.org/D144357
This patch adjusts the way dependencies are handled in the packaed
version of the GPU libc runtime. Previously the files were not getting
updated properly in the install when they changed.
Depends on D144214
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D144280
This patch unifies the handling of generating the GPU build targets
between the `add_entrypoint_library` and the `add_object_library`
functions. The `_build_gpu_objects` function will create two targets.
One contains a single object file with several GPU binaries embedded in
it, a so-called fatbinary. The other is a direct compile of the
supported target to be used internally only. This patch pulls out some
of the properties logic so that we can handle both more easily. This
patch also required adding an ovverride `NO_GPU_BUILD` for cases when
we only want to build the source file as normal.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D144214
The libc uses some functions that GCC does not currently
implement, that come from Arm's ACLE header usually.
These are:
```
__arm_wsr64
__arm_rsr64
__arm_wsr
__arm_rsr
```
This issue was reported to us (https://github.com/llvm/llvm-project/issues/60473)
and I've then reported that back to GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642).
Even if these functions are added, clang has some non standard extensions
to them that gcc may not take. So we're looking at a fix in gcc 13 at best,
and that may not be enough for what we're doing with them.
So I've added ifdefs to use alternatives with gcc.
For handling the stack pointer, inline assembly is unfortunately the only option.
I have verified that the single mov is essentially what __arm_rsr64 generates.
For fpsr and fpcr the gcc devs suggested using
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/AArch64-Built-in-Functions.html#AArch64-Built-in-Functions.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143261
The goal is to fuzz the entirety of printf, but the plan is to do it in
pieces for simplicity. This test fuzzes just the parser, while later
tests will fuzz the converters. This also adds a mock version of the
arg_list class.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143784
For testing purposes we need to be able to mock out the ArgList class.
This patch adds a mock version of that class as well as a flag to enable
it.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D144145
Summary:
This hack with stub files is used to make the final object archive
have human-understandable names. We currently output these into the
current binary directory, which sometimes interferes with the actual
source file. Put these in their own directory to be certain they don't
conflict.
This is the first attempt to get some testing support for GPUs in LLVM's
libc. We want to be able to compile for and call generic code while on
the device. This is difficult as most GPU applications also require the
support of large runtimes that may contain their own bugs (e.g. CUDA /
HIP / OpenMP / OpenCL / SYCL). The proposed solution is to provide a
"loader" utility that allows us to execute a "main" function on the GPU.
This patch implements a simple loader utility targeting the AMDHSA
runtime called `amdhsa_loader` that takes a GPU program as its first
argument. It will then attempt to load a predetermined `_start` kernel
inside that image and launch execution. The `_start` symbol is provided
by a `start` utility function that will be linked alongside the
application. Thus, this should allow us to run arbitrary code on the
user's GPU with the following steps for testing.
```
clang++ Start.cpp --target=amdgcn-amd-amdhsa -mcpu=<arch> -ffreestanding -nogpulib -nostdinc -nostdlib -c
clang++ Main.cpp --target=amdgcn-amd-amdhsa -mcpu=<arch> -nogpulib -nostdinc -nostdlib -c
clang++ Start.o Main.o --target=amdgcn-amd-amdhsa -o image
amdhsa_loader image <args, ...>
```
We determine the `-mcpu` value using the `amdgpu-arch` utility provided
either by `clang` or `rocm`. If `amdgpu-arch` isn't found or returns an
error we shouldn't run the tests as the machine does not have a valid
HSA compatible GPU. Alternatively we could make this utility in-source
to avoid the external dependency.
This patch provides a single test for this untility that simply checks
to see if we can compile an application containing a simple `main`
function and execute it.
The proposed solution in the future is to create an alternate
implementation of the LibcTest.cpp source that can be compiled and
launched using this utility. This approach should allow us to use the
same test sources as the other applications.
This is primarily a prototype, suggestions for how to better integrate
this with the existing LibC infastructure would be greatly appreciated.
The loader code should also be cleaned up somewhat. An implementation
for NVPTX will need to be written as well.
Reviewed By: sivachandra, JonChesterfield
Differential Revision: https://reviews.llvm.org/D139839
Properly set floating point exceptions and add more exceptional
values for non-FMA x86-64 targets.
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D143699
Fuzzing the string to integer and float functions without relying on the
system libc allows for tests to be run in a wider variety of places.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D143616
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
Before this change, the test binaries were executed only if the deps
changed. This change makes the test binaries run unconditionally. This
is more in line with the rest of LLVM. Future patches will print test
statistics etc., much like the rest of LLVM.
Reviewed By: gchatelet
Differential Revision: https://reviews.llvm.org/D143627
Previously the type description structs were defined in the parser. For
the fuzzing targets we'll need to use those, so I've moved them into
core_structs.h. Additionally I've renamed the function for determining
the TypeDesc from a given type. Previously it shared its name with
get_type_desc which is a related but separate function that is a part of
the parser.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D143595
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.
