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.
It's checked in a cmake function that builds up a list called
`config_options`. But the check was appending to a list called
`compile_options`, so the intended `-DLIBC_MATH=whatever` didn't end up
on the actual compile command lines.
In IEEE 754 and C standards, when calling `frexp` with Inf/Nan inputs,
the exponent result is unspecified. In this case, FreeBSD libc and musl
just passthrough `exp`, while glibc, FreeBSD libm set exp = 0, and MSVC
set exp = -1.
By default, LLVM libc will passthrough `exp` just as FreeBSD libc and
musl, but we also allow users to explicitly choose the return exp value
in this case for compatibility with other libc.
Notice that, gcc did generate passthrough `exp` for `frexp(NaN/Inf,
exp)`: https://godbolt.org/z/sM8fEej4E
Hi there,
When building llvm-libc on the openEuler system, I encountered an issue
as shown in the image below:
This issue happens because the regular expression used in
`libc/cmake/modules/LLVMLibCArchitectures.cmake`: `string(REGEX MATCH
"Target: [-_a-z0-9.]+[ \r\n]+")` does not handle capital letters
properly in `openEuler`.
To fix this, I modified the regular expression to: `string(REGEX MATCH
"Target: [-_a-zA-Z0-9.]+[ \r\n]+")`. This change makes it compatible
with capital letters.
Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.
Summary:
I initially thought that it would be convenient to automatically link
these libraries like they are for standard C/C++ targets. However, this
created issues when trying to use C++ as a GPU target. This patch moves
the logic to now implicitly pass it as part of the offloading toolchain
instead, if found. This means that the user needs to set the target
toolchain for the link job for automatic detection, but can still be
done manually via `-Xoffload-linker -lc`.
Fix a typo in the header generation message.
Before:
Generating header from
/home/vscode/llvm-project/llvm/../libc/newhdrgen/yaml/ctype.yaml and
/home/vscode/llvm-project/libc/include/ctype.h.def
After:
Generating header ctype.h from
/home/vscode/llvm-project/llvm/../libc/newhdrgen/yaml/ctype.yaml and
/home/vscode/llvm-project/libc/include/ctype.h.def
This PR first adds osutils for Windows, and changes some libc code to
make libc and its tests build on the Windows target. It then temporarily
disables some libc tests that are currently problematic on Windows.
Specifically, the changes besides the addition of osutils include:
- Macro `LIBC_TYPES_HAS_FLOAT16` is disabled on Windows. `clang-cl`
generates calls to functions in `compiler-rt` to handle float16
arithmetic and these functions are currently not linked in on Windows.
- Macro `LIBC_TYPES_HAS_INT128` is disabled on Windows.
- The invocation to `::aligned_malloc` is changed to an invocation to
`::_aligned_malloc`.
- The following unit tests are temporarily disabled because they
currently fail on Windows:
- `test.src.__support.big_int_test`
- `test.src.__support.arg_list_test`
- `test.src.fenv.getenv_and_setenv_test`
- Tests involving `__m128i`, `__m256i`, and `__m512i` in
`test.src.string.memory_utils.op_tests.cpp`
- `test_range_errors` in `libc/test/src/math/smoke/AddTest.h` and
`libc/test/src/math/smoke/SubTest.h`
Currently the nan* functions use nullptr dereferencing to crash with
SIGSEGV if the input is nullptr. Both `nan(nullptr)` and `nullptr`
dereferencing are undefined behaviors according to the C standard.
Employing `nullptr` dereference in the `nan` function implementation is
ok if users only linked against the pre-built library, but it might be
completely removed by the compilers' optimizations if it is built from
source together with the users' code.
See for instance: https://godbolt.org/z/fd8KcM9bx
This PR uses volatile load to prevent the undefined behavior if libc is
built without sanitizers, and leave the current undefined behavior if
libc is built with sanitizers, so that the undefined behavior can be
caught for users' codes.
The 32-bit Arm builds of libc define time_t to be `__INTPTR_TYPE__`,
i.e. a 32-bit integer. This is commented in the commit introducing it
(75398f28ebdb600) as being for compatibility with glibc. But in the near
future not even every AArch32 build of glibc will have a 32-bit time_t:
Debian is planning that their next release (trixie) will have switched
to 64-bit. And non-Linux builds of this libc (e.g. baremetal) have no
reason to need glibc compatibility in the first place – and every reason
_not_ to want to start using a 32-bit time_t in 2024 or later.
So I've replaced the `#ifdef` in `llvm-libc-types/time_t.h` with two
versions of the header file, chosen in `CMakeLists.txt` via a new
configuration option. This involved adding an extra parameter to the
cmake `add_header` function to specify different names for the header
file in the source and destination directories.
This PR changes several places in the CMake scripts to make libc build
on Windows. It adds the `errno` entrypoint to the Windows target.
A mistake in the overlay build doc is also fixed.
Tests still cannot be built on Windows because of the lack of osutils.
This is a non-feature change that enables most of the entrypoints for
aarch64 based runtime builds. It fixes an additional problem that some
compiler-rt targets are not defined at the time of dependency checking
thus leading to false-negatives.
Summary:
The `nvlink-wrapper` can do LTO now, which means we can still create
some LLVM-IR without needing an architecture. In the case that we try to
invoke `nvlink` internally, that will still fail. This patch simply
defers the error until later so we can use `--lto-emit-llvm` to get the
IR without specifying an architecture.
Summary:
The GPU build provides a bitcode version of the library to mimic how
NVIDIA and AMD provide their libraries. Previously we had the fatbinary
archive that created the necessary dependency for this to actually
build. Since it was removed we no longer had anything triggering this to
build.
I have no idea if there's a better way to force a custom command to
actually be run in the same space as libraries, but the only thing I
could come up with was a dummy target.
Summary:
The GPU build needs to be able to inline stuff in LTO. Builtin
transformations cause problems on the functions that the optimizer does
heavy libcall recognition on. Previously we moved to using
`-fno-builtin-*` to allow us to only disable the problematic ones.
However, this still didn't allow inlining because each function had the
attribute that told the inliner not to inlining a nobuiltin function
into a non-nobuiltin function
This patch fixes that by only applying these attributes to the
entrypoints that define them. That is enough to prevent recursive calls
within the definitoins themselves.
Summary:
I forgot that the OpenMP tests still look for this, reverting for now
until I can make a fix.
This reverts commit c1c6ed83e9ac13c511961e5f5791034a63168e7e.
Summary:
Previously, the GPU built the `libc` in a fat binary version that was
used to pass this to the link job in offloading languages like CUDA or
OpenMP. This was mostly required because NVIDIA couldn't consume the
standard static library version. Recent patches have now created the
`clang-nvlink-wrapper` which lets us do that. Now, the C library is just
included implicitly by the toolchain (or passed with -Xoffload-linker
-lc).
This code can be fully removed, which will heavily simplify the build
(and removed some bugs and garbage files I've encoutnered).
Summary:
The configs all need default values which targets then override. This
one was an empty string which made the logic report an error. The only
reason it wasn't a build failure was because of a stray `:`.
Summary:
Currently we have several hacks to work around the fact that the NVPTX
linker, 'nvlink', does not support static libraries or LTO linking.
The patch in https://github.com/llvm/llvm-project/pull/96561 introduces
a wrapper in the toolchain that allows us to use a standard `ld.lld`
like interface. This means all the divergence with this target can be
removed.
Depends on https://github.com/llvm/llvm-project/pull/96561
