On Linux using --version-script doesn't force loading of the underlying
archives that contain the symbols. By setting alwayslink=True on the API
cc_library we virtually get this behavior. This also allows downstream
users to use the exports files used by cmake. We could build more
configurability into this but there are also a lot of possible
variations users might want.
https://reviews.llvm.org/D54188 marked "alias" targets as used in C to
fix -Wunused false positives. This patch extends the approach to handle
mangled names to support global scope names in C++ and the
`overloadable` attribute in C.
(Note: we should skip `UsingShadowDecl`, which would trigger an
assertion failure in `ItaniumMangleContextImpl::mangleCXXName`.
See regression test added by commit 1c2afbae9af22b58190c10e3517242d01d89d612.)
In addition, we mark ifunc targets as used to fix#63957 (temporarily
used by xz; ifunc was removed by
689ae24273)
While our approach has false negatives for namespace scope names, the
majority of alias/ifunc C++ uses (global scope with no overloads) are
handled.
Note: The following function with internal linkage but C language
linkage type is mangled in Clang but not in GCC. This inconsistency
makes alias/ifunc difficult to use in C++ with portability (#88593).
```
extern "C" {
static void f0() {}
// GCC: void g0() __attribute__((alias("_ZL2f0v")));
// Clang: void g0() __attribute__((alias("f0")));
}
```
Pull Request: https://github.com/llvm/llvm-project/pull/87130
https://reviews.llvm.org/D54188 marked "alias" targets as used in C to
fix -Wunused false positives. This patch extends the approach to handle
mangled names to support global scope names in C++ and the
`overloadable` attribute in C.
In addition, we mark ifunc targets as used to fix#63957.
While our approach has false negatives for namespace scope names, the
majority of alias/ifunc C++ uses (global scope with no overloads) are
handled.
Note: The following function with internal linkage but C language
linkage type is mangled in Clang but not in GCC. This inconsistency
makes alias/ifunc difficult to use in C++ with portability (#88593).
```
extern "C" {
static void f0() {}
// GCC: void g0() __attribute__((alias("_ZL2f0v")));
// Clang: void g0() __attribute__((alias("f0")));
}
```
Pull Request: https://github.com/llvm/llvm-project/pull/87130
This commit is a code cleanup. It defines the test ops the are used for
the `ValueBoundsOpInterface` tests in TableGen, along with proper
verifiers.
---------
Co-authored-by: Benjamin Maxwell <benjamin.maxwell@arm.com>
The epoll_wait functions need the rest of the epoll functions (create,
ctl) to be available to actually test them, as well as pipe to create a
usable file descriptor. This patch adds epoll_create, epoll_create1,
epoll_ctl, and pipe. These have tests, and the tests for epoll_wait,
epoll_pwait, and epoll_pwait2 (currently disabled) are updated to use
these newly available functions.
When supporting "overlay" vs "fullbuild" modes, "what ABI are you
using?" becomes a fundamental question to have concrete answers for.
Overlay mode MUST match the ABI of the system being overlayed onto;
fullbuild more flexible (the only system ABI relevant is the OS kernel).
When implementing llvm-libc we generally prefer the include-what-you use
style of avoiding transitive dependencies (since that makes refactoring
headers more painful, and slows down build times). So what header do you
include for any given type or function declaration? For any given
userspace program, the answer is straightforward. But for llvm-libc
which is trying to support multiple ABIs (at least one per
configuration), the answer is perhaps less clear.
This proposal seeks to add one layer of indirection relative to what's
being done today.
It then converts users of sigset_t and struct epoll_event and the epoll
implemenations over to this convention as an example.
This implementation has a number of issues and ultimately does not work
on gfx9.
* It does not reduce bank conflicts with wide memory accesses.
* It does not correctly account for when LDS bank conflicts occur on
amdgpu.
* The implementation is too fragile to be used on real-world code. For
example, the code bails out on any `memref.subview` in the root op, even
when the subview is not a user of any of the `memref.alloc` ops.
I do not see how these can be easily fixed, therefore I think it's
better to delete this code.
Context: https://github.com/llvm/llvm-project/pull/87017
- Add proxy header `libc/hdr/math_macros.h` that will:
- include `<math.h>` in overlay mode,
- include `"include/llvm-libc-macros/math-macros.h"` in full build mode.
- Its corresponding CMake target `libc.hdr.math_macros` will only depend
on `libc.include.math` and `libc.include.llvm-libc-macros.math_macros`
in full build mode.
- Replace all `#include "include/llvm-libc-macros/math-macros.h"` with
`#include "hdr/math_macros.h"`.
- Add dependency to `libc.hdr.math_macros` CMake target when using
`add_fp_unittest`.
- Update the remaining dependency.
- Update bazel overlay: add `libc:hdr_math_macros` target, and replacing
all dependency on `libc:llvm_libc_macros_math_macros` with
`libc:hdr_math_macros`.
With these changes you can now `bazel build @llvm-project//...` on
macOS, and the targets in libc that don't yet support macOS (or
non-linux) are ignored
This adds build configuration for building LLDB on macOS and Linux. It
uses a default subset of features that should work out of the box with
macOS + Ubuntu. It is notably missing python support right now, although
some of the scaffolding is there, because of the complexity of linking a
python dylib, especially if you plan to distribute the resulting
liblldb.so.
Most of this build file is pretty simple, one of the unfortunate
patterns I had to use was to split the header and sources cc_library
targets to break circular dependencies.
Reverts llvm/llvm-project#86137
Some aarch64 compilers seem to consider that `uint128_t` is not
`is_trivially_constructible` which prevents `bit_cast`-ing.
This patch moves most of the multiprecision logic to the `multiword`
namespace and simplifies some logic in `BigInt`. It also fully
implements the mask and count functions and increases test coverage.
`math_extras.h` is also reworked to make it more concise.
This includes algorithm.h directly to provide the definition for
`cpp:max` in parser.h. This will define `max(...)` in the libc namespace
for build systems that pull in parser.h explicitly.
This adds the bazel equivalent of the `llvm` binary produced by
`LLVM_TOOL_LLVM_DRIVER_BUILD` in cmake. For the initial commit, this
only includes `llvm-ar`, `llvm-nm`, and `llvm-size`. The rest are
trivial to add in a followup commit, following the same pattern as here.
By default it will include everything that supports the llvm-driver
model, but it can be reduced to only build a subset, e.g. this will
build only nm and size:
```
$ bazel build \
--@llvm-project//llvm:driver-tools=llvm-nm,llvm-size \
@llvm-project//llvm:llvm
```
This is the second attempt of 32fcfcdc4cc1d68116438f761897953894d65fb1,
which had to be reverted.
This should be good to go now, after a number of cleanups to not expose
headers from multiple targets:
- 6e58efac16958ccb99060f4329b48737be7d8d36
- f1dff836593d4601e3ad78117df1d980d284bb9c
- 89ef3130cf16f1965475396ad3a50760558cc08a
- eb70b485a91361eee83d3744d1bd3e4c3a23692f
- 83e5a1239242d64110e3dfa96ed3889170ab96b2
- fce046ca5b7edb4c0d37a6eb580154ccb7dda966
