summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* workflows/release-tasks: Remove stray backslashrelease/16.xTom Stellard2023-05-161-1/+1
| | | | | | | | Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D150018 (cherry picked from commit afa607fbacfeb00643a034b99a28c1cf2cb86227)
* Bump version to 16.0.5Tom Stellard2023-05-164-4/+4
|
* [clangd] Fix builds after 4ddae8b941398a6579d3llvmorg-16.0.4Kadir Cetinkaya2023-05-162-9/+5
| | | | (cherry picked from commit 9ffef0f24de0fc05b946e662a7b233a32ad058e3)
* [clangd] Fix test failure when it's built with compiler flags unknown by clangXi Ruoyao2023-05-162-0/+11
| | | | | | | | | | | | | | If LLVM is built with a compiler other than clang, the `compile_commands.json` file may contain compiler flags unknown by clang. When a clangd test is copied into the build directory and checked, clangd will pick the unknown flag from the file and cause a test failure. Create an empty `compile_commands.json` in the test directory nested in the build directory to override it. Reviewed By: thesamesam Differential Revision: https://reviews.llvm.org/D150582 (cherry picked from commit 4ddae8b941398a6579d3a6f25aa39a260e441371)
* [Clang][BPF] Type print btf_type_tag properlyYonghong Song2023-05-164-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running bcc tool execsnoop ([1]) which is built with latest llvm, I hit the following error: $ sudo ./execsnoop.py /virtual/main.c:99:157: error: expected ')' data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (void *)&({ typeof(struct task_struct btf_type_tag(rcu)*) _val; __builtin_memset(&_val, 0, sizeof(_val)); ^ bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; }); The failure reason is due to that the bcc rewriter printed type like struct task_struct btf_type_tag(rcu)* where the compiler cannot recognize what 'btf_type_tag(rcu)' is. The above type is printed in [2] by UnaryOperator->getType().getAsString() (from clang) in function ProbeVisitor::VisitUnaryOperator. The original source type looks like ([3]) struct task_struct { ... struct task_struct __rcu *real_parent; ... } where '__rcu' is a macro expanding to '__attribute__((btf_type_tag("rcu")))'. Let us print btf_type_tag properly in clang so bcc tools and broader type printing will work properly. With this patch, the above rewrited source code looks like data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (void *)&({ typeof(struct task_struct __attribute__((btf_type_tag("rcu")))*) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; }); and execsnoop.py tool can run properly. [1] https://github.com/iovisor/bcc/blob/master/tools/exitsnoop.py [2] https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc [3] https://github.com/torvalds/linux/blob/master/include/linux/sched.h Differential Revision: https://reviews.llvm.org/D150017 (cherry picked from commit 3060304906f08f933672f0a30cc57d5f09766444)
* [SelectionDAG][RISCV] Remove code for handling too small shift type from ↵Craig Topper2023-05-162-6/+36
| | | | | | | | | | | | | | | | | | | | | | | | SimplifyDemandedBits. This code detected that the type returned from getShiftAmountTy was too small to hold the constant shift amount. But it used the full type size instead of scalar type size leading it to crash for scalable vectors. This code was necessary when getShiftAmountTy would always return the target preferred shift amount type for scalars even when the type was an illegal type larger than the target supported. For vectors, getShiftAmountTy has always returned the vector type. Fortunately, getShiftAmountTy was fixed a while ago to detect that the target's preferred size for scalars is not large enough for the type. So we can delete this code. Switched to use getShiftAmountConstant to further simplify the code. Fixs PR61561. (cherry picked from commit a37df84f99ebe68c3e9cc533ffd3952fb22d1f38)
* [Driver] Support multi /guard: optionsPhoebe Wang2023-05-163-2/+6
| | | | | | | | Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D150645 (cherry picked from commit 3b6f7e45a20990fdbc2b43dc08457fc79d53bd39)
* [cmake] Disable GCC lifetime DSEXi Ruoyao2023-05-161-0/+10
| | | | | | | | | | | | | | | | | | | | | LLVM data structures like llvm::User and llvm::MDNode rely on the value of object storage persisting beyond the lifetime of the object (#24952). This is not standard compliant and causes a runtime crash if LLVM is built with GCC and LTO enabled (#57740). Until these issues are fixed, we need to disable dead store eliminations eliminations based on object lifetime. The previous test issues are fixed by 626849c71e85d546a004cc91866beab610222194. Bug: https://github.com/llvm/llvm-project/issues/24952 Bug: https://github.com/llvm/llvm-project/issues/57740 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 Reviewed By: MaskRay, thesamesam, nikic Differential Revision: https://reviews.llvm.org/D150505 (cherry picked from commit 47f5c54f997a59bb2c65abe6b8b811f6e7553456)
* [clang-tidy][test] Add trailing -- to suppress compile_commands.json readFangrui Song2023-05-161-2/+2
| | | | | | | | This fixes some build bots if we reland D150505: specifically when using GCC to build LLVM and then `-fno-lifetime-dse` ends up passed to compile_commands.json and causing clang-tidy to pick up the Clang unknown option. (cherry picked from commit 626849c71e85d546a004cc91866beab610222194)
* fix stack probe lowering for x86_intrccTom Dohrmann2023-05-152-1/+30
| | | | | | | | | | | | | | The x86_intrcc calling convention will build two STACKALLOC_W_PROBING machine instructions if the function takes an error code. This is caused by an additional call to emitSPUpdate in llvm/lib/Target/X86/X86FrameLowering.cpp:1650. Previously only the first STACKALLOC_W_PROBING machine instruction was properly handled, the second one was simply ignored. This lead to miscompilations where the stack pointer wasn't properly updated (see https://github.com/rust-lang/rust/issues/109918). This patch fixes this by handling all STACKALLOC_W_PROBING machine instructions. To be honest I don't quite understand why this didn't lead to more noticeable miscompilations previously. This is my first time contributing to LLVM. Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D150033 (cherry picked from commit f6154364f65709df234f07ad1fe8799e68d84134)
* [flang] Fix optional assertion in PFTBuilderValentin Clement2023-05-152-1/+22
| | | | | | | | | | | | | D142279 enabled assertion in libstdc++ and one was triggered in the PFTBuilder because an optional was access even if it was null. This patch fix this issue and add a regression test. Reviewed By: jeanPerier Differential Revision: https://reviews.llvm.org/D143589 (cherry picked from commit 3f55311a0afff6278571922e1c23bf5c71dd2d0b)
* [clang] Fix default initializers being ignored when initializing templated ↵Alan Zhao2023-05-153-7/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | aggregate types Previously, when checking whether an in-class initializer exists when performing parenthesized aggregate initialization, Clang checks that the output of FieldDecl::getInClassInitializer() is non-null. This is incorrect; if the field is part of a templated type, then getInClassInitializer() will return nullptr if we haven't called Sem::BuildCXXDefaultInitExpr(...) before, even if FieldDecl::hasInClassInitializer() returns true. The end result is that Clang incorrectly ignores the in class initializer and value-initializes the field. The fix therefore is to instead call FieldDecl::hasInClassInitializer(), which is what we do for braced init lists [0]. Before this patch, Clang does correctly recognize the in-class field initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...) populates the in class initializer of the corresponding FieldDecl object. Therefore, if that method was previously called with the same FieldDecl object, as can happen with a decltype(...) or a braced list initialization, FieldDecl::getInClassInitializer() will return a non-null expression, and the field becomes properly initialized. Fixes 62266 [0]: https://github.com/llvm/llvm-project/blob/be5f35e24f4c15caf3c4aeccddc54c52560c28a0/clang/lib/Sema/SemaInit.cpp#L685 Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D149389
* Reapply "[SystemZ] Bugfix in expansion of memmem operations."Jonas Paulsson2023-05-132-2/+130
| | | | | | | | | | | | | | | | | | | | The new test case showed that the NoPHIs flag needs to be cleared. Original commit message: [SystemZ] Bugfix in expansion of memmem operations. Since NC, OC, and XC clobber CC, the EXRL_Pseudo targeting these must also be marked to do so. Original patch by uweigand. Reviewed by: uweigand Differential Revision: https://reviews.llvm.org/D150251 Fixes: https://github.com/llvm/llvm-project/issues/62572 (cherry picked from commit 655f0fc4b96d02b1baa075a0bbd8dda936070796)
* Bump version to 16.0.4Tom Stellard2023-05-054-4/+4
|
* [compiler-rt] [test] Mark dfsan tests XFAIL on glibc-2.37llvmorg-16.0.3Michał Górny2023-05-023-1/+7
| | | | | | | | | | | Mark the two dfsan tests that are known to be broken on glibc-2.37 as XFAIL, to make the test suite start passing on Gentoo again. Bug: https://github.com/llvm/llvm-project/issues/60678 Differential Revision: https://reviews.llvm.org/D148496 (cherry picked from commit 488a4b24817ae7d9319d8a99bd96c491b2035641)
* [clang][driver] Pass `-femulated-tls` through to the linker in LTO modePaul Kirth2023-05-022-0/+24
| | | | | | | | | | | | | | | | | | | | Currently the driver does not propagate the `-f[no-]emulated-tls` flags to the linker under LTO. This can be surprising when the platform defaults differ from the flags being passed. A related discussion can be found in https://reviews.llvm.org/D143619. While the focus there was RISC-V support, the root cause was that setting `-femualted-tls` and `-flto` when compiling with Clang resulted in missing symbols because the platform defaults for Android differed from the flags being passed to Clang. This patch changes the Clang driver's behavior to pass the emulated-tls flags through to the linker when compiling with LTO/ThinLTO. Reviewed By: phosek, vit9696 Differential Revision: https://reviews.llvm.org/D147834 (cherry picked from commit a78816a6b6debb548efbf1717aeeb490df42f401)
* [RuntimeDyld] Disable some ppc64 tests on 32-bit architectures.Lang Hames2023-05-022-0/+15
| | | | | | | These tests have been failing on 32-bit machines. https://github.com/llvm/llvm-project/issues/62184. (cherry picked from commit 2cd2fb4376187d4939e1eb7f18ba847d3b1668e3)
* [InstCombine] Fix buggy `(mul X, Y)` -> `(shl X, Log2(Y))` transform PR62175Noah Goldstein2023-05-011-14/+27
| | | | | | | | | | | | | | | | | | | | | | | Bug was because we recognized patterns like `(shl 4, Z)` as a power of 2 we could take Log2 of (`2 + Z`), but doing `(shl X, (2 + Z))` can cause a poison shift. https://alive2.llvm.org/ce/z/yuJm_k The fix is to verify that `Log2(Y)` will be a non-poisonous shift amount. We can do this with: `nsw` flag: - https://alive2.llvm.org/ce/z/yyyJBr - https://alive2.llvm.org/ce/z/YgubD_ `nuw` flag: - https://alive2.llvm.org/ce/z/-4mpyV - https://alive2.llvm.org/ce/z/a6ik6r Prove `Y != 0`: - https://alive2.llvm.org/ce/z/ced4su - https://alive2.llvm.org/ce/z/X-JJHb Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D148609
* [clang] Fix 2 bugs with parenthesized aggregate initializationAlan Zhao2023-05-015-15/+90
| | | | | | | | | | | | | | | | | | | | | * Fix an issue where temporaries initialized via parenthesized aggregate initialization don't get destroyed. * Fix an issue where aggregate initialization omits calls to class members' move constructors after a TreeTransform. This occurs because the CXXConstructExpr wrapping the call to the move constructor gets unboxed during a TreeTransform of the wrapping FunctionalCastExpr (as with a InitListExpr), but unlike InitListExpr, we dont reperform the InitializationSequence for the list's expressions to regenerate the CXXConstructExpr. This patch fixes this bug by treating CXXParenListInitExpr identically to InitListExpr in this regard. Fixes #61145 Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D146465 (cherry picked from commit 7df3c71b508b65284483225685f1ba19777f2bbb)
* Clear read_fd_set if EINTR receivedEmre Kultursay2023-05-011-3/+6
| | | | | | | | | | | | Leaving bits uncleared set causes callbacks to be triggered even though there are no events to process. Starting with D131160 we have a callback that makes blocking read calls over pipe which was causing the lldb-server main loop to become unresponsive / blocked on Android. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D144240
* [SimplifyCFG] Don't merge invoke if this makes immarg non-constant (PR61265)Nikita Popov2023-05-013-19/+67
| | | | | | | | | | | | | | | Don't merge invokes if this replaces constant operands with phis in a place where this is not legal. This also disallows converting operand bundles from constant to non-constant, in line with the restriction we use in other transforms. Fixes https://github.com/llvm/llvm-project/issues/61265. Differential Revision: https://reviews.llvm.org/D146723 (cherry picked from commit 11313108ff778ab6037dcf3d6057de6e1d26fb80)
* [clang] Fix a crash with parenthesized aggregate initialization and base classesAlan Zhao2023-05-013-2/+30
| | | | | | | | | | | | | | | | | | When calling InitializeBase(...), TryOrBuidlParenListInit(...) needs to pass in the parent entity; otherwise, we erroneously try to cast CurContext to a CXXConstructorDecl[0], which can't be done since we're performing aggregate initialization, not constructor initialization. Field initialization is not affected, but this patch still adds some tests for it. Fixes 62296 [0]: https://github.com/llvm/llvm-project/blob/33d6bd1c667456f7f4a9d338a7996a30a3af50a3/clang/lib/Sema/SemaAccess.cpp#L1696 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D149301
* [LLD][COFF] Add /inferasanlibs to lld-link as ignored flagAlvin Wong2023-05-014-0/+32
| | | | | | | | | | | | | | | | | | MSVC link.exe added this flag and MS STL started using this flag in .drectve [1] when compiling with Clang with asan enabled, as reported on https://github.com/llvm/llvm-project/issues/56300. This causes issues with lld-link because it rejects any unknown flags in .drective sections. As dc07867dc9991c982bd3441da19d6fcc16ea54d6 noted that, when using Clang as the driver it explicitly passes the proper asan libraries. Therefore it should be acceptable to ignore this flag in lld-link to at least unbreak building with clang-cl and linking with lld-link. [1]: https://github.com/microsoft/STL/blob/faaf094ee16bcbfb2c8d612fdb9334bcdef2fd0a/stl/inc/__msvc_sanitizer_annotate_container.hpp#L35 Differential Revision: https://reviews.llvm.org/D149023 (cherry picked from commit 8fa0cfeb61a12ad5ca7830a8228155de32aa7ab2)
* [LLD][COFF] Print object file name for unsupported directivesAlvin Wong2023-05-012-1/+17
| | | | | | | | | This is a small QoL improvement suggested by FrancescElies in https://github.com/llvm/llvm-project/issues/56300#issuecomment-1172104966. Differential Revision: https://reviews.llvm.org/D149022 (cherry picked from commit 9b15e9840f5073aa38939fbef1cb0c64dcc5f02f)
* [CodeGen][MachineLastInstrsCleanup] fix INLINEASM_BR hazardNick Desaulniers2023-05-012-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the removable definition resides in an INLINEASM_BR target, the reuseable candidate might not dominate the INLINEASM_BR. bb0: INLINEASM_BR &"" %bb.1 renamable $x8 = MOVi64imm 29273397577910035 B %bb.2 ... bb1: renamable $x8 = MOVi64imm 29273397577910035 renamable $x8 = ADDXri killed renamable $x8, 2048, 0 bb2: Removing the second mov is a hazard when the inline asm branches to bb1. Skip such replacements when the to be removed instruction is in the target of such an INLINEASM_BR instruction. We could get more aggressive about this in the future, but for now simply abort. This is causing a boot failure on linux-4.19.y branches of the LTS Linux kernel for ARCH=arm64 with CONFIG_RANDOMIZE_BASE=y (KASLR) and CONFIG_UNMAP_KERNEL_AT_EL0=y (KPTI). Link: https://reviews.llvm.org/D123394 Link: https://github.com/ClangBuiltLinux/linux/issues/1837 Thanks to @nathanchance for the report, and @ardb for debugging. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D149191 (cherry picked from commit 012ea747ed0275c499f69c82ac0f635f4c76f746)
* [CodeGen] precommit machine-latecleanup testNick Desaulniers2023-05-011-0/+259
| | | | | | | | | | | Demonstrates a hazard in machine-latecleanup. Differential Revision: https://reviews.llvm.org/D149190 (cherry picked from commit 095a0c67bb5705b2ebd91ecc039e73bbd6982cee) [nd: remove isOutlined MIR key due to missing commit 267708f9d515 ("[MachineOutliner] Add IsOutlined to MachineFunction")]
* [compiler-rt] Fix invalid triple on ARM buildLeandro Lupori2023-04-271-0/+19
| | | | | | | | | | | | | | The fuzzer build was failing on armv7l, with an invalid triple error. This happened because CMake's get_compiler_rt_target function was missing some code to correctly handle arm archs, such as armhf. This was originaly part of https://reviews.llvm.org/D140011, that landed on main with commit cd173cbd7cca69c29df42cd4b42e60433435c29b. Fixes #60115 Differential Revision: https://reviews.llvm.org/D142906
* [compiler-rt] Fix scudo build on ARMLeandro Lupori2023-04-271-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The build of scudo was failing on armv7l, with undefined references to unwinder symbols, such as __aeabi_unwind_cpp_pr0. These are needed by RTGwpAsan and thus, on ARM, scudo must also be linked against an unwind library. The cmake command that caused the build failure was: cmake --fresh -S "$PWD/llvm/" -B "$PWD/build/" -G Ninja \ -DCMAKE_INSTALL_PREFIX="$PWD/install" \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;polly" \ -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \ -DLLVM_TOOLCHAIN_TOOLS="llvm-ar;llvm-ranlib;llvm-objdump;\ llvm-rc;llvm-cvtres;llvm-nm;llvm-strings;llvm-readobj;\ llvm-dlltool;llvm-pdbutil;llvm-objcopy;llvm-strip;llvm-cov;\ llvm-profdata;llvm-addr2line;llvm-symbolizer;llvm-windres;llvm-ml;\ llvm-readelf;llvm-size" \ -DLLVM_INSTALL_BINUTILS_SYMLINKS=OFF -DLLVM_PARALLEL_LINK_JOBS=1 Fixes #60115 Reviewed By: hctim Differential Revision: https://reviews.llvm.org/D142888 (cherry picked from commit e1e972689b9138db795885a5468a15aafbe7cb51)
* workflows/release-tasks: Always run apt-get update before installing depsTom Stellard2023-04-201-0/+1
| | | | | | | | | | | | | | | | | | There is a bug in the package tree of on the default images that causes some dependencies not to be found. Running apt-get gets us the latest package lists rather than relying on the default lists in the GitHub Runner imgae, which can be up to a week old. Running apt-get update before intstalling packages is also recommended in the official github documentation: https://docs.github.com/en/actions/using-github-hosted-runners/customizing-github-hosted-runners#installing-software-on-ubuntu-runners Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D148741 (cherry picked from commit 93d6289c987a68c463079100c25d601e71153f2f)
* workflows/release-binaries: Install missing dependenciesTom Stellard2023-04-201-0/+1
| | | | | | | | Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D148772 (cherry picked from commit 74acaf1809a47833ad973826d6f0f76c2261247e)
* [docs] Add missing Clang release note.Tobias Hieta2023-04-201-0/+1
| | | | Adding this on behalf of yueh.ting.chen@gmail.com.
* workflows/release-binaries: Add missing output variableTom Stellard2023-04-191-0/+1
| | | | | | | | Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D148734 (cherry picked from commit cd39791350ed9b327ca3dbc8f3ab61d21beb6b69)
* Bump version to 16.0.3Tom Stellard2023-04-194-4/+4
|
* Remove UB-implying metadata when promoting speculative instruction.llvmorg-16.0.2DianQK2023-04-182-2/+28
| | | | | | | | | | After D138238 introduced the then/else blocks, we should remove UB-implying metadata for the promoted speculative instruction. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D148456 (cherry picked from commit 2832d7941f4207f1fcf813b27cf08cecc3086959)
* [runtimes][asan] Fix swapcontext interceptionIvan Trofimov2023-04-184-39/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resetting oucp's stack to zero in swapcontext interception is incorrect, since it breaks ucp cleanup after swapcontext returns in some cases: Say we have two contexts, A and B, and we swapcontext from A to B, do some work on Bs stack and then swapcontext back from B to A. At this point shadow memory of Bs stack is in arbitrary state, but since we can't know whether B will ever swapcontext-ed to again we clean up it's shadow memory, because otherwise it remains poisoned and blows in completely unrelated places when heap-allocated memory of Bs context gets reused later (see https://github.com/llvm/llvm-project/issues/58633 for example). swapcontext prototype is swapcontext(ucontext* oucp, ucontext* ucp), so in this example A is oucp and B is ucp, and i refer to the process of cleaning up Bs shadow memory as ucp cleanup. About how it breaks: Take the same example with A and B: when we swapcontext back from B to A the oucp parameter of swapcontext is actually B, and current trunk resets its stack in a way that it becomes "uncleanupable" later. It works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is performed for Bs stack after B "returns" to A second time. That's exactly what happens in the test i provided, and it's actually a pretty common real world scenario. Instead of resetting oucp's we make use of uc_stack.ss_flags to mark context as "cleanup-able" by storing stack specific hash. It should be safe since this field is not used in [get|make|swap]context functions and is hopefully never meaningfully used in real-world scenarios (and i haven't seen any). Fixes https://github.com/llvm/llvm-project/issues/58633 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D137654 (cherry picked from commit b380e8b68951776656f286ecd079e2f30981905e)
* [nfc][asan] Reformat the fileVitaly Buka2023-04-181-65/+65
| | | | (cherry picked from commit 3248ca0da01c73711896ddc86ae8b045b86726c8)
* [test][asan] Simplify testVitaly Buka2023-04-181-14/+4
| | | | | | FileCheck is not very useful here. (cherry picked from commit fd2cafbdc480920bcf4eb598788a906ec1f63c41)
* llvm-exegesis: Only run target specfic tests on native hostsTom Stellard2023-04-182-0/+6
| | | | | | | | | | | | These tests were failing on SystemZ hosts, I don't think JIT'ing non-SystemZ modules on SystemZ is supported. The tests were initiallay enabled on all arches by 7a76140220bd2c4730a2c39b6fd645402040f011. Differential Revision: https://reviews.llvm.org/D145763 (cherry picked from commit e30ce634f75c01cc8784cb0c4972c42987178c1d)
* github: Add manual workflow to build and upload release binariesJack Grigg2023-04-182-0/+147
| | | | | | | | Reviewed By: kwk Differential Revision: https://reviews.llvm.org/D143535 (cherry picked from commit 5b8156bf623042c857150cb9a6039d7e775d90e4)
* [flang] Complex numbers in function arguments on WindowsMarkus Mützel2023-04-182-4/+362
| | | | | | | | | | | | | | | | Function arguments or return values that are complex floating point values aren't correctly lowered for Windows x86 32-bit and 64-bit targets. See: https://github.com/llvm/llvm-project/issues/61976 Add targets that are specific for these platforms and OS. With thanks to @mstorsjo for pointing out the fix. Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D147768 (cherry picked from commit 774703ec08f62d702d40e1f97cd35ae5f732c544)
* [clang-format] Fix regression with AlignTrailingComments set to trueOwen Pan2023-04-172-10/+10
| | | | | | | | Fixes #62161. Differential Revision: https://reviews.llvm.org/D148447 (cherry picked from commit 2bcfff6708d293abab87a4d5a1dff25950d55d91)
* Revert "[clang-format] Handle object instansiation in if-statements"Tobias Hieta2023-04-172-20/+1
| | | | | | | | This reverts commit 70de684d44135b4025d92b2b36ad387cf5ab8b5a. This causes a regression as described in #61785 (cherry picked from commit 104cd749f5cca609a79303c0dad22bc041b5448a)
* [StackProtector] don't check stack protector before calling nounwind functionsNick Desaulniers2023-04-173-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://reviews.llvm.org/rGd656ae28095726830f9beb8dbd4d69f5144ef821 introduced a additional checks before calling noreturn functions in response to this security paper related to Catch Handler Oriented Programming (CHOP): https://download.vusec.net/papers/chop_ndss23.pdf See also: https://bugs.chromium.org/p/llvm/issues/detail?id=30 This causes stack canaries to be inserted in C code which was unexpected; we noticed certain Linux kernel trees stopped booting after this (in functions trying to initialize the stack canary itself). https://github.com/ClangBuiltLinux/linux/issues/1815 There is no point checking the stack canary like this when exceptions are disabled (-fno-exceptions or function is marked noexcept) or for C code. The GCC patch for this issue does something similar: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7 Android measured a 2% regression in RSS as a result of d656ae280957 and undid it globally: https://android-review.googlesource.com/c/platform/build/soong/+/2524336 Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D147975 (cherry picked from commit fc4494dffa5422b2be5442c235554e76bed79c8a)
* [libunwind][LoongArch] Restore $r1 before $r4 in `jumpto`Weining Lu2023-04-172-7/+2
| | | | | | | | | | | | | $ra should be restored before $a0, otherwise the baseaddress ($a0) would be destroyed. See file `UnwindRegistersSave.S` for reference. This also makes libcxx and libcxxabi regtest pass for the `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` build. Reviewed By: MaskRay, xen0n, #libunwind Differential Revision: https://reviews.llvm.org/D147372 (cherry picked from commit ff0aabf14dfa0a369c38f6e267c56a83ee48d647)
* [libunwind][test] Add test to check for unw_resume()zhanglimin2023-04-171-0/+39
| | | | | | | | | | | | This is here for local unwinding, which unw_resume() restores the machine state and then directly resumes execution in the target stack frame. Reviewed By: wangleiat Differential Revision: https://reviews.llvm.org/D147371 (cherry picked from commit 366c5474a3002114b8980ab278d93baa96046385)
* [AArch64] Basic target(+crypto) handlingDavid Green2023-04-172-1/+54
| | | | | | | | | | This adds some basic handling for target(+crypto) attributes. In this patch it just enabled aes and sha2 regardless of the architecture revision, which matches gccs implementation (and keeps the patch simple). Differential Revision: https://reviews.llvm.org/D142135 (cherry picked from commit 43aa293aeaf04e8da50c3c531694444c0311e0c5)
* [Support] Improve Windows performance of buffered raw_ostreamAndrew Ng2023-04-141-0/+7
| | | | | | | | | | | | | | | | | | The "preferred" buffer size for raw_ostream is set to BUFSIZ which on Windows is only 512. This results in more calls to write and this overhead can have a significant negative impact on performance, especially when Anti-Virus is also involved. Therefore increase the "preferred" buffer size to 16KB for Windows. One example of where this helps is the LLD --Map option which dumps out the symbol map for a link. In a link of UE4, this change has been seen to improve the performance of the symbol map writing by more than a factor of 6. Differential Revision: https://reviews.llvm.org/D147340 (cherry picked from commit a3aa916d019c8deb10c750acecdef650b3365f22)
* [LinkerWrapper] Switch to add_clang_tool() macroEvangelos Foutras2023-04-141-5/+1
| | | | | | | | | | | | Summary: This creates install-clang-linker-wrapper{,-stripped} targets which are useful for Linux distro builds when using LLVM_DISTRIBUTION_COMPONENTS. Fixes: https://bugs.archlinux.org/task/77814 Differential Revision: https://reviews.llvm.org/D145862 (cherry picked from commit c2aabcfc8395ba30884dd3c1ecc2b192ae85a78d)
* Bump version to 16.0.2Tom Stellard2023-04-044-4/+4
|
* [SPARC] Attempt to fix bug introduced by D142458llvmorg-16.0.1Vitaly Buka2023-04-041-1/+1
| | | | | | Reported https://lab.llvm.org/buildbot/#/builders/5/builds/32113 (cherry picked from commit ea4cbbbfa4207c30888acffc499c8fc71cd3d84f)
View Lorry Controller Status