aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-06-10[lld][WebAssembly] Fix stub library parsing with windows line endingsllvmorg-16.0.6release/16.xSam Clegg3-8/+15
Also, fix checking of first line in ::parse. We can't use the ::getLines helper here since that already does comment stripping internally. Differential Revision: https://reviews.llvm.org/D147548 (cherry picked from commit d9d840cdaf51a9795930750d1b91d614a3849137)
2023-06-10Bump version to 16.0.6Tom Stellard4-4/+4
2023-06-01[clang] Fix crash when passing a braced-init list to a parentehsized ↵llvmorg-16.0.5Alan Zhao3-1/+10
aggregate init expression The previous code incorrectly assumed that we would never call warnBracedScalarInit(...) with a EK_ParenAggInitMember. This patch fixes the bug by warning when a scalar member is initialized via a braced-init list when performing a parentehsized aggregate initialization. This behavior is consistent with parentehsized list aggregate initialization. Fixes #63008 Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D151763
2023-06-01[AA] Fix comparison of AliasResults (PR63019)Nikita Popov2-4/+12
Comparison between two AliasResults implicitly decayed to comparison of AliasResult::Kind. As a result, MergeAliasResults() ended up considering two PartialAlias results with different offsets as equivalent. Fix this by adding an operator== implementation. To stay compatible with extensive use of comparisons between AliasResult and AliasResult::Kind, add an overload for that as well, which will ignore the offset. In the future, it would probably be a good idea to remove these implicit decays to AliasResult::Kind and add dedicated methods to check for specific AliasResult kinds. Fixes https://github.com/llvm/llvm-project/issues/63019. (cherry picked from commit 97f0e7b06e6b76fd85fb81b8c12eba2255ff1742)
2023-06-01[GVN] Add test for PR63019 (NFC)Nikita Popov1-0/+42
(cherry picked from commit 4d64ffa94170eadd79954e2a5f13d1f1d16e9e2c)
2023-06-01[X86][BF16] Fix 2 crashes with vector broadcastPhoebe Wang3-5/+74
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D151808 (cherry picked from commit 801dd8870fe3634e81e35e88519477541d1b0119)
2023-06-01[Analysis][LoongArch] Add sign extension for i32 parameters and returnszhanglimin4-9/+26
In LoongArch ABI spec, we can see that in the LP64D ABI, unsigned 32-bit types, such as unsigned int, are stored in general-purpose registers as proper sign extensions of their 32-bit values. Reference: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_abi_lp64d Reviewed By: SixWeining, xen0n Differential Revision: https://reviews.llvm.org/D151794 (cherry picked from commit fe6716a49850be09291f0eded6fb8ffa9f5cc651)
2023-06-01[lld][WebAssembly] Initial support for stub librariesSam Clegg14-5/+224
See the docs in lld/docs/WebAssembly.rst for more on this. This feature unlocks a lot of simplification in the emscripten toolchain since we can represent the JS libraries to wasm-ld as stub libraries. See https://github.com/emscripten-core/emscripten/issues/18875 Differential Revision: https://reviews.llvm.org/D145308 (cherry picked from commit 3111784ff7d3d51a9e981b1a0bbc8f6511c34d25)
2023-06-01[lld][WebAssembly] Implement --why-extract flag from the ELF backendSam Clegg5-8/+143
See https://reviews.llvm.org/D109572 for the original ELF version. Differential Revision: https://reviews.llvm.org/D145431 (cherry picked from commit 8aef04fa69a2a78fecdbc4d57174d773a7e5f2df)
2023-05-31[Clang][Sema] Fix invalid cast when validating SVE types within ↵Paul Walker2-1/+12
CheckVariableDeclarationType. Fixes #62087 Differential Revision: https://reviews.llvm.org/D148919 (cherry picked from commit 2bb7e00b098cdbf87b9e2e2f5ec85b661664b709)
2023-05-31[clang] Fix crash when handling nested immediate invocationsMariya Podchishchaeva4-8/+62
Before this patch it was expected that if there was several immediate invocations they all belong to the same expression evaluation context. During parsing of non local variable initializer a new evaluation context is pushed, so code like this ``` namespace scope { struct channel { consteval channel(const char* name) noexcept { } }; consteval const char* make_channel_name(const char* name) { return name;} channel rsx_log(make_channel_name("rsx_log")); } ``` produced a nested immediate invocation whose subexpressions are attached to different expression evaluation contexts. The constructor call belongs to TU context and `make_channel_name` call to context of variable initializer. This patch removes this assumption and adds tracking of previously failed immediate invocations, so it is possible when handling an immediate invocation th check that its subexpressions from possibly another evaluation context contains errors and not produce duplicate diagnostics. Fixes https://github.com/llvm/llvm-project/issues/58207 Reviewed By: aaron.ballman, shafik Differential Revision: https://reviews.llvm.org/D146234 (cherry picked from commit a5e1a93ea10ffc06a32df6d9f410e9b297ed136d)
2023-05-31[CMake][AIX] Fixing AIX rpathQiongsi Wu1-4/+5
Recent commit https://github.com/llvm/llvm-project/commit/8f833f88ab78265a8e0ebb0d1522771d67c708a9 modified the installation rpath and did not set `BUILD_WITH_INSTALL_RPATH` correctly on AIX, which led to installation failures on AIX. This patch sets `BUILD_WITH_INSTALL_RPATH` on AIX to fix the installation failures. Reviewed By: buttaface, daltenty Differential Revision: https://reviews.llvm.org/D148866 (cherry picked from commit 887828d502b49a09e56551e370cc6c1555ae3ff4)
2023-05-31[CMake] Don't set absolute paths as install runpaths on ELF platforms in ↵Butta2-6/+13
llvm_setup_rpath() If any LLVM subprojects are built separately, the LLVM build directory LLVM_LIBRARY_DIR is added to both the build and install runpaths in llvm_setup_rpath(), which is incorrect when installed. Separate the build and install runpaths on ELF platforms and finally remove the incorrect call to this function for compiler-rt, as previously attempted in 21c008d5a5b. That prior attempt was reverted in 959dbd1761c, where it was said to break the build on macOS and Windows, so I made sure to keep those platforms the same. Two examples of incorrect runpaths that are currently added, one from the latest LLVM 16 toolchain for linux x86_64: > readelf -d clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.*so | ag "File:|runpath" File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.dyndd.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan_aliases.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.memprof.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.scudo_standalone.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.tsan.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_minimal.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_standalone.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib] Another is in the Swift toolchain, which builds lldb separately: > readelf -d swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/{bin/lldb*,lib/liblldb.so}|ag "File:|runpath" File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib] File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-argdumper 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib] File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-server 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib] File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/lib/liblldb.so 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib:/home/build-user/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux:$ORIGIN/../lib/swift/linux] This patch should fix this problem of absolute paths from the build host leaking out into the toolchain's runpaths. Differential revision: https://reviews.llvm.org/D146918 (cherry picked from commit 8f833f88ab78265a8e0ebb0d1522771d67c708a9)
2023-05-30Revert DSE workarounds, this was causing some problems in main.Tom Stellard3-19/+2
Revert "[clangd] Fix builds after 4ddae8b941398a6579d3" This reverts commit ae42196bc493ffe877a7e3dff8be32035dea4d07. Revert "[clangd] Fix test failure when it's built with compiler flags unknown by clang" This reverts commit 21f3dfbc26736e4299c154e67065652f48279047. Revert "[cmake] Disable GCC lifetime DSE" This reverts commit d5cce0a7781bfbb9322a2e9625c7f88253801148. Revert "[clang-tidy][test] Add trailing -- to suppress compile_commands.json read" This reverts commit 57262bbd32c35eb05bac34e39a751abc0466b9da.
2023-05-30[clang] Fix overly aggressive lifetime checks for parenthesized aggregate ↵Alan Zhao7-147/+345
initialization Before this patch, initialized class members would have the LifetimeKind LK_MemInitializer, which does not allow for binding a temporary to a reference. Binding to a temporary however is allowed in parenthesized aggregate initialization, even if it leads to a dangling reference. To fix this, we create a new EntityKind, EK_ParenAggInitMember, which has LifetimeKind LK_FullExpression. This patch does *not* attempt to diagnose dangling references as a result of using this feature. This patch also refactors TryOrBuildParenListInitialization(...) to accomodate creating different InitializedEntity objects. Fixes #61567 [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D148274
2023-05-30[CMake] Set compatibility policy for lists in LLVM-Config.cmake.Marcelo Juchem1-0/+5
Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4". When building [latest `iovisor/bcc`](https://github.com/iovisor/bcc/commit/1ea0390725391e76256af6a4d0eb857816e6290f), `cmake` complains about a change in the behavior of operator `IN_LIST`: ```console CMake Warning (dev) at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if): Policy CMP0057 is not set: Support new IN_LIST if() operator. Run "cmake --help-policy CMP0057" for policy details. Use the cmake_policy command to set the policy and suppress this warning. IN_LIST will be interpreted as an operator when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. Call Stack (most recent call first): cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames) src/cc/CMakeLists.txt:132 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Error at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if): if given arguments: "engine" "IN_LIST" "link_components" Unknown arguments specified Call Stack (most recent call first): cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames) src/cc/CMakeLists.txt:132 (include) ``` This patch addresses this issue by setting the aforementioned policy in `LLVM-Config.cmake`. Reviewed By: mgorny, thesamesam Differential Revision: https://reviews.llvm.org/D150884 Closes: https://github.com/llvm/llvm-project/issues/61436 (cherry picked from commit 75a0502fe0053c72b57b61143a55600814d931fd)
2023-05-30[clang-format] Handle <chrono> ud suffixes in IntegerLiteralSeparatorOwen Pan2-1/+23
Fixes #62679. Differential Revision: https://reviews.llvm.org/D150539 (cherry picked from commit a72b064acf9546ee41c67c77ed8662d5d3b2fadc)
2023-05-30[BOLT][CMake] Use correct output paths and passthrough necessary optionsPetr Hosek3-5/+11
This addresses https://github.com/llvm/llvm-project/issues/62748. Differential Revision: https://reviews.llvm.org/D150752
2023-05-30[Hexagon] Add patterns for bspap/bitreverse for scalar vectorsKrzysztof Parzyszek3-102/+360
Fixes https://github.com/llvm/llvm-project/issues/62474 (cherry picked from commit c7b291a63f5cabea47e1b4b13e7091e3e37dadb1)
2023-05-30[llvm-mca] Fix duplicate symbols errorMichael Maitland2-8/+19
Parsing instruments and analysis regions causes us to see the same labels two times since we parse the same file twice under the same context. This change creates a seperate context for instrument parsing and another for analysis region parsing. I will post a follow up commit once I get some free cycles to parse analysis regions and instruments in one parsing pass under a single context. Differential Revision: https://reviews.llvm.org/D149781 (cherry picked from commit 1c2b8129e99478a9b0222fc0aaf44a4a47e7ecd6)
2023-05-30Reland "[Driver] Support multi /guard: options"Phoebe Wang3-2/+10
Fixes unexpected warning. Differential Revision: https://reviews.llvm.org/D150645 (cherry picked from commit 2f0a1699eab7c00a64312e7f87e0d85a2e9b9e6e)
2023-05-30Revert "[Driver] Support multi /guard: options"Arthur Eubanks3-6/+2
This reverts commit 3b6f7e45a20990fdbc2b43dc08457fc79d53bd39. See comments on D150645. (cherry picked from commit 3d7903f1008febc80cb104eedcbcd31d2690839f)
2023-05-30[X86] Don't crash on instruction prefetch intrinsics without PREFETCHI support.Craig Topper2-1/+19
Instead of failing to select during isel, drop the intrinsic in lowering. Fixes PR62839. Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D151050 (cherry picked from commit 022aefa59c28323d961603abaa34caaffe273ee4)
2023-05-18Fix ArgsAsWritten being null for ConceptSpecializationExpr in certainWalter Gray4-5/+27
circumstances when parsing ASTs Fix ArgsAsWritten being null for ConceptSpecializationExpr in certain circumstances when parsing ASTs ASTStmtWriter::VisitConceptSpecializationExpr specifically expects getTemplateArgsAsWritten() to return true, which it wasn't when parsed by ASTContext.cpp in certain edge cases. Fixes: #61486 Differential Revision: https://reviews.llvm.org/D146678 (cherry picked from commit 1f48a1fce23551cc24f5b598af5994f5cfc6b6d0) Add additional overload to prevent API break.
2023-05-16workflows/release-tasks: Remove stray backslashTom Stellard1-1/+1
Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D150018 (cherry picked from commit afa607fbacfeb00643a034b99a28c1cf2cb86227)
2023-05-16Bump version to 16.0.5Tom Stellard4-4/+4
2023-05-16[clangd] Fix builds after 4ddae8b941398a6579d3llvmorg-16.0.4Kadir Cetinkaya2-9/+5
(cherry picked from commit 9ffef0f24de0fc05b946e662a7b233a32ad058e3)
2023-05-16[clangd] Fix test failure when it's built with compiler flags unknown by clangXi Ruoyao2-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)
2023-05-16[Clang][BPF] Type print btf_type_tag properlyYonghong Song4-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)
2023-05-16[SelectionDAG][RISCV] Remove code for handling too small shift type from ↵Craig Topper2-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)
2023-05-16[Driver] Support multi /guard: optionsPhoebe Wang3-2/+6
Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D150645 (cherry picked from commit 3b6f7e45a20990fdbc2b43dc08457fc79d53bd39)
2023-05-16[cmake] Disable GCC lifetime DSEXi Ruoyao1-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)
2023-05-16[clang-tidy][test] Add trailing -- to suppress compile_commands.json readFangrui Song1-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)
2023-05-15fix stack probe lowering for x86_intrccTom Dohrmann2-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)
2023-05-15[flang] Fix optional assertion in PFTBuilderValentin Clement2-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)
2023-05-15[clang] Fix default initializers being ignored when initializing templated ↵Alan Zhao3-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
2023-05-13Reapply "[SystemZ] Bugfix in expansion of memmem operations."Jonas Paulsson2-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)
2023-05-05Bump version to 16.0.4Tom Stellard4-4/+4
2023-05-02[compiler-rt] [test] Mark dfsan tests XFAIL on glibc-2.37llvmorg-16.0.3Michał Górny3-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)
2023-05-02[clang][driver] Pass `-femulated-tls` through to the linker in LTO modePaul Kirth2-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)
2023-05-02[RuntimeDyld] Disable some ppc64 tests on 32-bit architectures.Lang Hames2-0/+15
These tests have been failing on 32-bit machines. https://github.com/llvm/llvm-project/issues/62184. (cherry picked from commit 2cd2fb4376187d4939e1eb7f18ba847d3b1668e3)
2023-05-01[InstCombine] Fix buggy `(mul X, Y)` -> `(shl X, Log2(Y))` transform PR62175Noah Goldstein1-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
2023-05-01[clang] Fix 2 bugs with parenthesized aggregate initializationAlan Zhao5-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)
2023-05-01Clear read_fd_set if EINTR receivedEmre Kultursay1-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
2023-05-01[SimplifyCFG] Don't merge invoke if this makes immarg non-constant (PR61265)Nikita Popov3-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)
2023-05-01[clang] Fix a crash with parenthesized aggregate initialization and base classesAlan Zhao3-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
2023-05-01[LLD][COFF] Add /inferasanlibs to lld-link as ignored flagAlvin Wong4-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)
2023-05-01[LLD][COFF] Print object file name for unsupported directivesAlvin Wong2-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)
2023-05-01[CodeGen][MachineLastInstrsCleanup] fix INLINEASM_BR hazardNick Desaulniers2-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)
2023-05-01[CodeGen] precommit machine-latecleanup testNick Desaulniers1-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")]
generated by cgit v1.1 at 2024-10-02 10:32:32 +0000