We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Done according to @phosek's comments in D117537, but not done then to
separate pure refactor (that) from possible behavior change (this).
Wasn't working before, but I think that was due to an issue of mismatched variable names fixed in D110005.
Reviewed By: phosek, #libunwind, #libc_abi
Differential Revision: https://reviews.llvm.org/D117833
Initial platform support for COFF/x86_64.
Completed features:
* Statically linked orc runtime.
* Full linking/initialization of static/dynamic vc runtimes and microsoft stl libraries.
* SEH exception handling.
* Full static initializers support
* dlfns
* JIT side symbol lookup/dispatch
Things to note:
* It uses vc runtime libraries found in vc toolchain installations.
* Bootstrapping state is separated because when statically linking orc runtime it needs microsoft stl functions to initialize the orc runtime, but static initializers need to be ran in order to fully initialize stl libraries.
* Process symbols can't be used blidnly on msvc platform; otherwise duplicate definition error gets generated. If process symbols are used, it's destined to get out-of-reach error at some point.
* Atexit currently not handled -- will be handled in the follow-up patches.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D130479
#56854 shows a backwards compatibility problem when builtins of compiler-rt don't follow ABI. We need to prevent to fall into the trap again for BF16.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D131147
Instead of detecting `_Float16` support at CMake configuration time,
detect it at compile time by checking for the predefined (by the
compiler) macro `__FLT16_MAX__` instead.
This solves the issue where compiler-rt is built simultaneously for both
x86_64 and i386 targets, and the CMake configuration uses x86_64
compilation to detect `_Float16` support, while it may not be supported
by the i386 target (if it does not have SSE2).
While here, rename `COMPILERT_RT_HAS_FLOAT16` to `CRT_HAS_FLOAT16`, to
conform more to the naming style used in `int_lib.h` and `int_types.h`.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D130718
Depends on D129371.
It survived all GCC ASan tests.
Changes are trivial and mostly "borrowed" RISC-V logics, except that a different SHADOW_OFFSET is used.
Reviewed By: SixWeining, MaskRay, XiaodongLoong
Differential Revision: https://reviews.llvm.org/D129418
Initial libsanitizer support for LoongArch. It survived all GCC UBSan tests.
Major changes:
1. LoongArch port of Linux kernel only supports `statx` for `stat` and its families. So we need to add `statx_to_stat` and use it for `stat`-like libcalls. The logic is "borrowed" from Glibc.
2. `sanitizer_syscall_linux_loongarch64.inc` is mostly duplicated from RISC-V port, as the syscall interface is almost same.
Reviewed By: SixWeining, MaskRay, XiaodongLoong, vitalybuka
Differential Revision: https://reviews.llvm.org/D129371
This caused build failures when building Clang and libc++ together on Mac:
fatal error: 'experimental/memory_resource' file not found
See the code review for details. Reverting until the problem and how to
solve it is better understood.
(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)
> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927
This reverts commit bb939931a1.
`add_dependencies(${LIB_PARENT_TARGET} aix-${libname})` should only happen when `aix-${libname}` is added.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D129433
This is a follow up to D118200 which applies a similar cleanup to
headers when using in-tree libc++ to avoid accidentally picking up
the system headers.
Differential Revision: https://reviews.llvm.org/D128035
This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.
Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.
Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.
Differential Revision: https://reviews.llvm.org/D128927
We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.
Differential Revision: https://reviews.llvm.org/D126905
We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.
Differential Revision: https://reviews.llvm.org/D126905
This avoids the need for string-ification and lets CMake deduplicate
potentially duplicate flags.
Differential Revision: https://reviews.llvm.org/D122750
When `compiler-rt` is configured as a runtime, the configure-time target
detection for builtins is done in compile-only mode, which is basically a
test of whether the newly-built `clang` can compile a simple program with
an additional flag (`-m32` and `-m64` in my case). The problem is that on
my Debian system `clang` can compile `int foo(int x, int y) { return x + y; }`
with `-m32` but fails to include `limits.h` (or any other target-specific
header) for the `i386` target:
```
$ /path/to/build/./bin/clang --target=x86_64-unknown-linux-gnu -DVISIBILITY_HIDDEN -O3 -DNDEBUG -m32 -std=c11 -fPIC -fno-builtin -fvisibility=hidden -fomit-frame-pointer -MD -MT CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -MF CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o.d -o CMakeFiles/clang_rt.builtins-i386.dir/absvdi2.c.o -c /path/to/src/compiler-rt/lib/builtins/absvdi2.c
In file included from /path/to/src/compiler-rt/lib/builtins/absvdi2.c:13:
In file included from /path/to/src/compiler-rt/lib/builtins/int_lib.h:93:
In file included from /path/to/build/lib/clang/15.0.0/include/limits.h:21:
In file included from /usr/include/limits.h:25:
/usr/include/features.h:364:12: fatal error: 'sys/cdefs.h' file not found
^~~~~~~~~~~~~
1 error generated.
```
This is an attempt to make the target detection more robust: extend the test
program with `#include <limits.h>`.
Differential Revision: https://reviews.llvm.org/D127975
Similar to D120946, pass LIBCXX_HAS_GCC_S_LIB and LIBCXX_USE_COMPILER_RT
through to the custom lib++ builds so that libfuzzer doesn't end up with
a .deplibs section that links against those libraries when the
variables are set to false.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D127912
This allows configuring LLVM unwinder separately from the C++ library
matching how we configure it in libcxx.
This also applies changes made to libunwind+libcxxabi+libcxx in D113253
to compiler-rt.
Differential Revision: https://reviews.llvm.org/D115674
Profile library are written by standard libraries or POSIX calls depend on target support, so there is no porting effort for the target, we could enable that for both RV32 and RV64, verified on the RV64 platform.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124599
This avoids the need for string-ification and lets CMake deduplicate
potentially duplicate flags.
Differential Revision: https://reviews.llvm.org/D122750
Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on more
parts of compiler-rt than before, but should ideally not make any
difference assuming the other runtimes that lacked the option
also were C11 compatible.
Not marking this as required, to match the existing behaviour (where
`-std=c11` was added only if supported by the compiler).
This was suggested during the review of D110005.
Differential Revision: https://reviews.llvm.org/D124343
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
This reverts commit 3469cb14e2.
Relanding the patch on behalf of Byoungchan Lee.
The original patch (8a3afc6da5) was
reverted because it appeared to be landed without the approval
of an Apple engineer.
After internal discussion we're happy for this to land and I've
formally approved the patch in phabricator
(https://reviews.llvm.org/D119174).
rdar://92134140
This reverts commit 8a3afc6da5.
The commit being was landed without review from any Apple engineers
which is problematic because the patch only affects Apple platforms.
rdar://92134140
This patch is the reland of a8e5ce76b4,
which includes additional SDK version checks to ensure that
XCode's headers support arm64 builds.
Differential Revision: https://reviews.llvm.org/D119174
Like D118875, but for ubsan, asan, etc.
With this, I can successfully run:
bin/clang++ -target x86_64-apple-ios14.0-macabi foo.cc \
-isysroot $(xcrun -show-sdk-path) -fsanitize=undefined
with a locally built libclang_rt.ubsan_osx_dynamic.dylib.
Differential Revision: https://reviews.llvm.org/D124059
This piece of code tries to implement the semantics "cross compile?" to
determine CFLAGS used for test binary compilation.
```
if(ANDROID OR ${arch} MATCHES "arm|aarch64|riscv32|riscv64")
```
Since Apple Silicon, macOS runs on arm64e, so we take the wrong branch
when compiling and running tests locally "on the host" on an AS machine.
Furthermore, for Apple code, we use the separate
`get_test_cflags_for_apple_platform` function to determine these test
compiliation flags and `get_test_cc_for_arch` is only ever used in the
"compile & run on host" case, so we can short-curcuit the "cross
compile?" check here.
rdar://91446703
Differential Revision: https://reviews.llvm.org/D123633
ld64 implicitly ad-hoc code-signs as of Xcode 12, and `strip` and friends know
how keep this special ad-hoc signature valid.
So this should have no effective behavior change, except that you can now strip
libclang_rt.asan_osx_dynamic.dylib and it'll still have a valid ad-hoc
signature, instead of strip printing "warning: changes being made to the file
will invalidate the code signature in:" and making the ad-hoc code signature
invalid.
Differential Revision: https://reviews.llvm.org/D123475
John Ericson