Re-branch swift/master from swift/master-rebranch #1729
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit 44613bb)
This reverts commit 844f018.
(cherry picked from commit 13796d1)
… when the loc VT is a different size than the original element. For example a v4f16 argument is scalarized to 4 i32 values. So the values are spread out instead of being packed tightly like in the original vector. Fixes PR47000. (cherry picked from commit 08b2d0a)
(cherry picked from commit a046f43)
(cherry picked from commit 16ffef2)
(cherry picked from commit 7379f9a)
No need to run this test with the multiple variants. (cherry picked from commit dbf44b8)
(cherry picked from commit a97dfdc)
…API.py
This test is flaky on Green Dragon as it often fails when the process state
is "Invalid" in the assert:
self.assertEqual(process.GetState(), lldb.eStateExited)
It seems this is related to just doing "run" which apparently invalidates
the Target's process in case it's still running and needs to be restarted.
Just doing 'continue' on the process (and ignoring the error in case it already
finished) prevents that and makes this consistently pass for me.
Just pushing this out to get Green Dragon back online.
(cherry picked from commit bb4efab)
The test checks the inferior's output. During replay the binary doesn't actually run and the output isn't captured by the reproducers. (cherry picked from commit 9c5e25a)
Test target api
…806bcb91c622fc1f8641e010b [lldb] Remove XFAIL from now passing TestPtrRefs/TestPtreRefsObjC
Use new libReflection API when reading ELF files
…-rebranch Enables tests passing after fix of parsing elf object files
…rs-rebranch Enables Linux tests with old rdars
The implicit conversion from `nullptr_t` to `bool` is not permitted on Windows.
```
lldb\source\Plugins\Language\Swift\SwiftUnsafeTypes.cpp(316,12): error: cannot initialize return object of type 'bool' with an rvalue of type 'nullptr_t'
return nullptr;
^~~~~~~
```
Explicit return a `false` instead.
Swift: Fix the Windows build
Differential Revision: https://reviews.llvm.org/D85977
Fixes a build break.
Convert std::string to StringRef
(cherry picked from commit 4eb4ebf)
This is the follow up patch for https://reviews.llvm.org/D86183 as we miss to delete the node if NegX == NegY, which has use after we create the node. ``` if (NegX && (CostX <= CostY)) { Cost = std::min(CostX, CostZ); RemoveDeadNode(NegY); return DAG.getNode(Opcode, DL, VT, NegX, Y, NegZ, Flags); #<-- NegY is used here if NegY == NegX. } ``` Reviewed By: spatel Differential Revision: https://reviews.llvm.org/D86689 (cherry picked from commit deb4b25)
Tests on Solaris/sparcv9 currently show about 250 failures when building with gcc, most of them like the following: FAIL: LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures (4269 of 67884) ******************** TEST 'LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures' FAILED ******************** Note: Google Test filter = TaskQueueTest.UnOrderedFutures [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from TaskQueueTest [ RUN ] TaskQueueTest.UnOrderedFutures 0 SupportTests 0x0000000100753b20 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 32 1 SupportTests 0x0000000100752974 llvm::sys::RunSignalHandlers() + 68 2 SupportTests 0x0000000100752b18 SignalHandler(int) + 372 3 libc.so.1 0xffffffff7eedc800 __sighndlr + 12 4 libc.so.1 0xffffffff7eecf23c call_user_handler + 852 5 libc.so.1 0xffffffff7eecf594 sigacthandler + 84 6 SupportTests 0x00000001006f8cb8 std::thread::_State_impl<std::thread::_Invoker<std::tuple<llvm::ThreadPool::ThreadPool(llvm::ThreadPoolStrategy)::'lambda'()> > >::_M_run() + 512 7 libstdc++.so.6.0.28 0xfffffffc628117cc execute_native_thread_routine + 16 8 libc.so.1 0xffffffff7eedc6a0 _lwp_start + 0 Since it's effectively impossible to debug such a `SEGV` in a `Release` build, I tried a `Debug` build instead, only to find that the failures had gone away. Further investigation revealed that most of the issue centers around `llvm/lib/Support/ThreadPool.cpp`. That file is built with `-O3 -fPIC` in a `Release` build. The failure vanishes if - compiling without `-fPIC` - compiling with `-O -fPIC` - linking with GNU `ld` instead of Solaris `ld` It has meanwhile been determined that `gcc` doesn't correctly heed some TLS code sequences. To make things worse, Solaris `ld` doesn't properly validate its assumptions against the input, generating wrong code. `gld` like `gcc` is more liberal here and correctly deals with the code it gets fed from `gcc`. There's PR target/96607: GCC feeds SPARC/Solaris linker with unrecognized TLS sequences <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607> now. An attempt to build with `-DLLVM_ENABLE_PIC=Off` initially failed since neither `libRemarks.so` (D85626 <https://reviews.llvm.org/D85626>) nor `LLVMPolly.so` (D85627 <https://reviews.llvm.org/D85627>) heed that option. Even with that fixed, a few codegen failures remain. Next I tried to build just `ThreadPool.cpp` with `-O -fPIC`. While that fixed the vast majority of the failures, 16 `LLVM :: CodeGen/X86` failures remained. Given that that solution was both incomplete and fragile, I went for building the whole tree with `-O -fPIC` for `Release` and `RelWithDebInfo` builds. As detailed in Bug 47304, 2-stage builds also show large numbers of failures when building with `-O3` or `-O2`, which are likewise worked around by building with `-O` until they are sufficiently analyzed and fixed. This way, all failures relative to a `Debug` build go away. Tested on `sparcv9-sun-solaris2.11`. Differential Revision: https://reviews.llvm.org/D85630 (cherry picked from commit 15c66b1)
(cherry picked from commit 4fbf063)
Solves issue https://reviews.llvm.org/D86131#2247275 Reviewed By: hans Differential Revision: https://reviews.llvm.org/D86875 (cherry picked from commit f787c9a)
…(PR47322) Replace the check for poison-producing instructions in SimplifyWithOpReplaced() with the generic helper canCreatePoison() that properly handles poisonous shifts and thus avoids the problem from PR47322. This additionally fixes a bug in IIQ.UseInstrInfo=false mode, which previously could have caused this code to ignore poison flags. Setting UseInstrInfo=false should reduce the possible optimizations, not increase them. This is not a full solution to the problem, as poison could be introduced more indirectly. This is just a minimal, easy to backport fix. Differential Revision: https://reviews.llvm.org/D86834 (cherry picked from commit a5be86f)
…ter-rebranch Conflicts: lldb/source/Core/ValueObjectVariable.cpp
…-change [master-rebranch] Fix GetTypeInfo for changes to decodeMangledType in Swift.
Makefile.rules no longer decomposes the TRIPLE variable. Therefor we must pass the target directly.
…when the block literal is in a conditional context Previously, clang was crashing on the attached test because the EH cleanup for the block capture was incorrectly emitted under the assumption that the expression wasn't conditionally evaluated. This was because before 9a52de00260, pushLifetimeExtendedDestroy was mainly used with C++ automatic lifetime extension, where a conditionally evaluated expression wasn't possible. Now that we're using this path for block captures, we need to handle this case. rdar://66250047 Differential revision: https://reviews.llvm.org/D86854
[lldb] Fix TestSwiftCustomTriple.py after upstream TRIPLE logic change
Summary: PPC only supports the instruction selection for v16i8, v8i16, v4i32, v2i64, v4f32 and v2f64 for ISD::SETCC, don't support the v1i128, so v1i128 for ISD::SETCC will crash. This patch is to set v1i128 to expand to avoid crash. Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D84238 (cherry picked from commit 802c043)
[CodeGen] Make sure the EH cleanup for block captures is conditional …
|
@swift-ci test |
|
🤞 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.