For some reason cmake usually turns this path into an absolute path, but
sometimes
it doesn't do it and stays as a relative path, which means the command
will fail.
Specify it as an absolute path always so this doesn't happen any more.
Fixes [#141505](https://github.com/llvm/llvm-project/issues/141505)
The main intention behind this PR is to update the
LibCTargetArchitecture for arm64 to use the implementation of aarch64
architecture and not arm32.
This is a historical issue , and is a blocker to issue #138407.
The intended fix is to set the `LibCTargetArchitecture` to aarch64 when
it matches arm64 , this in turn would help us run darwin/aarch64
specific code on our MacOs pipeline in the git actions.
Methods used to search and find "darwin/arm" directories was
1. "find . -type d -path "*/libc/*/darwin/arm" in a linux terminal to
check for arm specifically
2. "find . -type d -path "*/libc/*/darwin/*" to ensure there are no
directories that are named "*arm*" where star is a wildcard for any
character.
It seems we were missing a dependency when adding a new test target,
e.g., test libc.test.src.math.sqrt_test.__unit__ would create a
custom target in the form of:
```
add_custom_target(
libc.test.src.__support.FPUtil.dyadic_float_test.__unit__
COMMAND ${LIBC_UNITTEST_ENV} ${CMAKE_CROSSCOMPILING_EMULATOR} libc.test.src.__support.FPUtil.dyadic_float_test.__unit__.__build__
COMMENT Running unit test libc.test.src.__support.FPUtil.dyadic_float_test.__unit__ )
```
but it wouldn't set that it depends on
libc.test.src.__support.FPUtil.dyadic_float_test.__unit__.__build__
being built.
For some reason, it would break the rv32 buildbot, as it would try to
run a test but the __build__ is nowhere to be found, since it wasn't
built in the first place.
Summary:
Previously, we removed the special handling for the code object version
global. I erroneously thought that this meant we cold get rid of this
weird `-Xclang` option. However, this also emits an LLVM IR module flag,
which will then cause linking issues.
Summary:
When we were first porting to COV5, this lead to some ABI issues due to
a change in how we looked up the work group size. Bitcode libraries
relied on the builtins to emit code, but this was changed between
versions. This prevented the bitcode libraries, like OpenMP or libc,
from being used for both COV4 and COV5. The solution was to have this
'none' functionality which effectively emitted code that branched off of
a global to resolve to either version.
This isn't a great solution because it forced every TU to have this
variable in it. The patch in
https://github.com/llvm/llvm-project/pull/131033 removed support for
COV4 from OpenMP, which was the only consumer of this functionality.
Other users like HIP and OpenCL did not use this because they linked the
ROCm Device Library directly which has its own handling (The name was
borrowed from it after all).
So, now that we don't need to worry about backward compatibility with
COV4, we can remove this special handling. Users can still emit COV4
code, this simply removes the special handling used to make the OpenMP
device runtime bitcode version agnostic.
Initial UEFI OS target support after the headers. This just defines
enough that stuff might try and compile. Test with:
```
$ cmake -S llvm -B build -G Ninja -DLLVM_RUNTIME_TARGETS=x86_64-unknown-uefi-llvm -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_ENABLE_RUNTIMES=libc -DRUNTIMES_x86_64-unknown-uefi-llvm_LLVM_LIBC_FULL_BUILD=true -DCMAKE_C_COMPILER_WORKS=true -DCMAKE_CXX_COMPILER_WORKS=true -DLLVM_ENABLE_PROJECTS="clang;lld" -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LIBCXX=true -DLLVM_HOST_TRIPLE=aarch64-unknown-linux-gnu -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-uefi-llvm -DCMAKE_INSTALL_LIBDIR=build/target/lib
$ ninja -C build
```
This reverts commit 1e6e845d49a336e9da7ca6c576ec45c0b419b5f6 because it
changed the 1st parameter of adjust() to be unsigned, but libc itself
calls adjust() with a negative argument in align_backward() in
op_generic.h.
DATA_FILES CMake argument never existed in the new YAML-based hdrgen
version of add_gen_header function, and thus its uses added in
b1fd6f0996a9d6e6ebfa0cc3df0fe499c5ccdf65 were always dead code.
Remove them to clean up the function implementation.
Co-authored-by: Alexey Samsonov <samsonov@google.com>
Summary:
Currently we conditionally enable NVPTX lowering depending on the
language (C/C++/OpenMP). Unfortunately this causes problems because this
option is only present if the backend was enabled, which causes this to
error if you try to make LLVM-IR.
This patch instead makes it the only accepted lowering. The reason we
had it as opt-in before is because it is not handled by CUDA. So, this
pach also introduces diagnostics to prevent *all* creation of
device-side global constructors and destructors. We already did this for
variables, now we do it for attributes as well.
This inverts the responsibility of blocking this from the backend to the
langauage like it should be given that support for this is language
dependent.
While GCC's -Wdeprecated is on by default and doesn't do much,
Clang's -Wdeprecated enables many more things. More apply in
C++20, so switch a test file that tickled one to using that. In
future, C++20 should probably be made the baseline for compiling
all the libc code.
This PR aims to add the groundwork to test the precision of libc complex
functions against MPC. I took `cargf` as a test to verify that the infra
works fine.
Summary:
This introduces libc cache files and adds one for building the GPU
support. The cache files will set defaults for these arguments which can
be overridden if the user needs to. They also serve as documentation for
how the builid is expected to look.
Found while trying to consolidate our command line flags between tests and
underlying object files.
error: extra ';' after member function definition [-Werror,-Wextra-semi]
Link: #119281
They're only used in that file, which is more appropriate than
LLVMLibCCompileOptionRules.cmake since they're strictly related to tests.
Remove unused flags param from _get_hermetic_test_compile_options, and flags
that were already set by a prior call to _get_common_test_compile_options.
This adds a test that consists of compiling `#include <...>`,
pretty much alone, for each public header file in each different
language mode (`-std=...` compiler switch) with -Werror and many
warnings enabled.
There are several headers that have bugs when used alone, and
many more headers that have bugs in certain language modes. So
for now, compiling the new tests is gated on the cmake switch
-DLLVM_LIBC_BUILD_HEADER_TESTS=ON. When all the bugs are fixed,
the switch will be removed so future regressions don't land.
This avoids touching the output file when it hasn't changed. The
cmake build integration now uses this so that touching a .yaml or
.h.def file in ways that don't affect the generated header output
won't cause unnecessary recompilations.
This adds a new main command-line entry point for hdrgen, in the
new main.py. This new interface is used for generating a header.
The old ways of invoking yaml_to_classes.py for other purposes
are left there for now, but `--e` is renamed to `--entry-point`
for consistency with the new CLI.
The YAML schema is expanded with the `header_template` key where
the corresponding `.h.def` file's path is given relative to where
the YAML file is found. The build integration no longer gives
the `.h.def` path on the command line. Instead, the script now
emits a depfile that's used by the cmake rules to track that.
The output file is always explicit in the script command line
rather than sometimes being derived from a directory path.
docgen relies on the convention that we have a file foo.cpp in
libc/src/\<header\>/. Because the above functions weren't in libc/src/strings/
but rather libc/src/string/, docgen could not find that we had implemented
these.
Rather than add special carve outs to docgen, let's fix up our sources for
these 7 functions to stick with the existing conventions the rest of the
codebase follows.
Link: #118860Fixes: #118875
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
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.
