summaryrefslogtreecommitdiff
path: root/contrib/llvm-project/compiler-rt
Commit message (Collapse)AuthorAgeFilesLines
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-09-164-19/+12
| | | | | | | | | | release/11.x llvmorg-11.0.0-rc2-91-g6e042866c30. MFC after: 6 weeks X-MFC-With: r364284 Notes: svn path=/head/; revision=365807
* Add atomic and bswap functions to libcompiler_rtDimitry Andric2020-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | There have been several mentions on our mailing lists about missing atomic functions in our system libraries (e.g. __atomic_load_8 and friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too. To address this, add implementations for the functions from compiler-rt to the system compiler support libraries, e.g. libcompiler_rt.a and and libgcc_s.so. This also needs a small fixup in compiler-rt's atomic.c, to ensure that 32-bit mips can build correctly. Bump __FreeBSD_version to make it easier for port maintainers to detect when these functions were added. MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26159 Notes: svn path=/head/; revision=364753
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-08-151-3/+3
| | | | | | | release/11.x llvmorg-11.0.0-rc1-47-gff47911ddfc. Notes: svn path=/projects/clang1100-import/; revision=364253
* r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 linesDimitry Andric2020-08-061-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PowerPC] enable atomic.c in compiler_rt and do not check and forces lock/lock_free decisions in compiled time Summary: Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime decision about lock/lock_free. At compiling time, if clang can't decide if atomic operation can be lock free, it emits calls to external functions like `__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and `__atomic_always_lock_free`, postponing decision to a runtime check. According to LLVM code documentation, the mechanism exists due to differences between x86_64 processors that can't be decided at runtime. On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock free, so we force the decision at compile time and avoid having to implement it in an external library. This patch was made after 32 bit users testing the PowePC32 bit ISO reported llvm could not be compiled with in-base llvm due to `__atomic_load8` not implemented. Submitted by: alfredo.junior_eldorado.org.br Reviewed by: jhibbits, dim Differential Revision: https://reviews.freebsd.org/D22549 Notes: svn path=/projects/clang1100-import/; revision=363977
* Reapply r354347 (by cem):Dimitry Andric2020-08-061-1/+16
| | | | | | | | | | | | | | | | | | | | | | Fix llvm-libunwind userspace build on ARM GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM. Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt. No functional change intended for non-ARM architectures. This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway). Notes: svn path=/projects/clang1100-import/; revision=363975
* Reapply r329859 (partially, by imp):Dimitry Andric2020-08-061-0/+4
| | | | | | | | | | | | Do not include float interfaces when using libsa. We don't support float in the boot loaders, so don't include interfaces for float or double in systems headers. In addition, take the unusual step of spiking double and float to prevent any more accidental seepage. Notes: svn path=/projects/clang1100-import/; revision=363963
* Undo r230021 again, further shrinking the diff against upstream.Dimitry Andric2020-08-031-23/+0
| | | | | | | | | | | This revision worked around an endless recursion when compiling clzdi2.c and ctzdi2.c with gcc, upstream landed a different workaround for this in https://reviews.llvm.org/rL324593, which is effective enough. Noticed by: jrtc27 Notes: svn path=/projects/clang1100-import/; revision=363803
* Reapply r326600 (by imp):Dimitry Andric2020-08-021-1/+5
| | | | | | | | | | | | Since this is contrib code, create an upstreamable version of my change. Now on FreeBSD and NetBSD if _STANDALONE is defined, we include the kernel version with alloances for the quirky differences between the two. Sponsored by: Netflix Notes: svn path=/projects/clang1100-import/; revision=363778
* Reapply r322168 (partially, by br):Dimitry Andric2020-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o Replace __riscv__ with __riscv o Replace __riscv64 with (__riscv && __riscv_xlen == 64) This is required to support new GCC 7.1 compiler. This is compatible with current GCC 6.1 compiler. RISC-V is extensible ISA and the idea here is to have built-in define per each extension, so together with __riscv we will have some subset of these as well (depending on -march string passed to compiler): __riscv_compressed __riscv_atomic __riscv_mul __riscv_div __riscv_muldiv __riscv_fdiv __riscv_fsqrt __riscv_float_abi_soft __riscv_float_abi_single __riscv_float_abi_double __riscv_cmodel_medlow __riscv_cmodel_medany __riscv_cmodel_pic __riscv_xlen Reviewed by: ngie Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D11901 Notes: svn path=/projects/clang1100-import/; revision=363777
* Reapply r230021, r276851 and a few other commits to compiler-rtDimitry Andric2020-08-021-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply r230021 (by ed): Add a workaround to prevent endless recursion in compiler-rt. SPARC and MIPS CPUs don't have special instructions to count leading/trailing zeroes. The compiler-rt library provides fallback rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are implemented as simple wrappers around the compiler built-in __builtin_clz(), assuming these will expand to either 32-bit CPU instructions or calls to __clzsi2 and __ctzsi2. Unfortunately, our GCC 4.2 probably thinks that because the operand is stored in a 64-bit register, it might just be a better idea to invoke its 64-bit equivalent, simply resulting into endless recursion. Fix this by defining __builtin_clz and __builtin_ctz to __clzsi2 and __ctzsi2 explicitly. Reapply r276851: Update compiler-rt to trunk r224034. This brings a number of new builtins, and also the various sanitizers. Support for these will be added in a later commit. Notes: svn path=/projects/clang1100-import/; revision=363773
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-07-311-53/+50
| | | | | | | release/11.x llvmorg-11-init-20933-g3c1fca803bc. Notes: svn path=/projects/clang1100-import/; revision=363743
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-07-31295-3563/+8222
| | | | | | | | | | | | master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from which release/11.x was branched. Note that for now, I rolled back all our local changes to make merging easier, and I will reapply the still-relevant ones after updating to 11.0.0-rc1. Notes: svn path=/projects/clang1100-import/; revision=363742
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-06-283-19/+46
| | | | | | | | | | | | | | | | llvmorg-10.0.1-rc2-0-g77d76b71d7d. Also add a few more llvm utilities under WITH_CLANG_EXTRAS: * llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into .dwp (DWARF package files) * llvm-size, a size(1) replacement * llvm-strings, a strings(1) replacement MFC after: 3 weeks Notes: svn path=/head/; revision=362719
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2020-05-231-2/+52
| | | | | | | | | llvmorg-10.0.1-rc1-0-gf79cd71e145 (aka 10.0.1 rc1). MFC after: 3 weeks Notes: svn path=/head/; revision=361410
* Merge ^/vendor/llvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-02-271-24/+1
| | | | | | | commit llvmorg-10.0.0-rc2-70-ge5cb70267e7), and bump versions. Notes: svn path=/projects/clang1000-import/; revision=358399
* Merge ^/vendor/llvm-project/release-10.x up to its last change (upstreamDimitry Andric2020-02-151-1/+8
| | | | | | | | commit llvmorg-10.0.0-rc2-0-g90c78073f73), bump versions, and update build glue. Notes: svn path=/projects/clang1000-import/; revision=357964
* Merge ^/vendor/lvm-project/master up to its last change (upstream commitDimitry Andric2020-01-24121-768/+2558
| | | | | | | e26a78e70), and resolve conflicts. Notes: svn path=/projects/clang1000-import/; revision=357095
* Merge ^/vendor/compiler-rt/dist up to its last change, and resolve conflicts.Dimitry Andric2020-01-22374-3107/+4609
| | | | Notes: svn path=/projects/clang1000-import/; revision=356999
* [PowerPC] enable atomic.c in compiler_rt and do not check and forcesJustin Hibbits2019-12-261-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | lock/lock_free decisions in compiled time Summary: Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime decision about lock/lock_free. At compiling time, if clang can't decide if atomic operation can be lock free, it emits calls to external functions like `__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and `__atomic_always_lock_free`, postponing decision to a runtime check. According to LLVM code documentation, the mechanism exists due to differences between x86_64 processors that can't be decided at runtime. On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock free, so we force the decision at compile time and avoid having to implement it in an external library. This patch was made after 32 bit users testing the PowePC32 bit ISO reported llvm could not be compiled with in-base llvm due to `__atomic_load8` not implemented. Submitted by: alfredo.junior_eldorado.org.br Reviewed by: jhibbits, dim Differential Revision: https://reviews.freebsd.org/D22549 Notes: svn path=/head/; revision=356104
* Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmpDimitry Andric2019-12-221-2/+7
| | | | | | | | | | | | | | | | | | 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05. Release notes for llvm, clang, lld and libc++ 9.0.1 will become available here: https://releases.llvm.org/9.0.1/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month Notes: svn path=/head/; revision=356004
* Consolidate FREEBSD-Xlist files of different llvm sub-projects into one.Dimitry Andric2019-12-201-71/+0
| | | | Notes: svn path=/head/; revision=355959
* Move all sources from the llvm project into contrib/llvm-project.Dimitry Andric2019-12-201041-0/+190842
This uses the new layout of the upstream repository, which was recently migrated to GitHub, and converted into a "monorepo". That is, most of the earlier separate sub-projects with their own branches and tags were consolidated into one top-level directory, and are now branched and tagged together. Updating the vendor area to match this layout is next. Notes: svn path=/head/; revision=355940
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-23 09:11:38 +0000