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
When crosscompiling, we need to search for the linux kernel headers in the sysroot but since #97486 the linux kernel headers were always searched in /usr/include.
This patch fixes this behaviour by prepending a '=' to where we search for the kernel headers. As per the gcc/clang's documentation a '=' before the path is replaced by the sysroot.
This patch also includes a fix for rv32, that fails to compile due to a missing definition of CLOCK_REALTIME after this change.
The DECLS_FILE_PATH property is supposed to be set on the targets for
the generated headers for the GPU build installation. It got missed when
creating the cmake rule for new headergen.
Summary:
This patch removed the `-ffreestanding` and `-fno-builtin` flags from
the publically installed version of the GPU library. The presense of
`-fno-builtin` caused issues that prevented all inlining in the GPU C
library, see
https://discourse.llvm.org/t/rfc-libc-ffreestanding-fno-builtin/75883.
Previously, I attempted to fix this by loosening the restriction that
`"no-builtins"` functions cannot be inlined into functions without that
attribute. However, that opened up a lot of extra issues that stalled
that approach.
This patch instead removes that and instead passes `-fno-builtin-<xyz>`
for the few calls that are known to be problematic. I believe this works
in general as the GPU backends do not emit any libcalls and the
implementations of most of these simply reduce to builtins right now.
This is a very useful patch as we can now actually inline calls.
PR for adding microbenchmarking infrastructure for NVPTX. `nvlink`
cannot perform LTO, so we cannot inline `libc` functions and this
function call overhead is not adjusted for during microbenchmarking.
Summary:
This patch adds `CMAKE_REQUIRED_FLAGS` for the GPU build so checks like
`check_cxx_compiler_flags` work as expected. This is required because we
need to hack around the potential lack of `nvlink` and `ptxas` for NVPTX
targets and the fact that the AMDGPU target needs `-nogpulib` to avoid
errors on lack of ROCm. This makes a few of the checks pass and also
allows us to just check `-mcpu=native` for architecture detection
instead of finding the tools manually.
Reverts llvm/llvm-project#95419 and Reland #95358.
This PR is full of temporal fixes. After a discussion with @lntue, it is
better to avoid further changes to the cmake infrastructure for now as a
rework to the cmake utilities will be landed in the future.
Summary:
These tools need to be built before we can do the library creation
stage. If they are generated in the same build then this is not
guaranteed so we should add explicit dependencies.
