forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 341
Merge db98a70056ad8e84f90487ca3ea4205f2243dae2 into 5.5 #2958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
JDevlieghere
merged 15 commits into
swift/release/5.5
from
merge-db98a70056ad8e84f90487ca3ea4205f2243dae2-into-5.5
May 13, 2021
Merged
Merge db98a70056ad8e84f90487ca3ea4205f2243dae2 into 5.5 #2958
JDevlieghere
merged 15 commits into
swift/release/5.5
from
merge-db98a70056ad8e84f90487ca3ea4205f2243dae2-into-5.5
May 13, 2021
Conversation
This file contains hidden or 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
This reverts commit b7c987b since it introduces a failure in `dwarf5-debug_line-file-index.s` and refactors `SymbolFileDWARF::ResolveSymbolContext` to use a `SourceLocationSpec`. rdar://73218201
Revert "[lldb] Use CompileUnit::ResolveSymbolContext in SymbolFileDWARF"
[lldb] Fix compilation in SymbolFileDWARF.cpp
…t fetch more packets. This looks like just an oversight in the AsyncThread function. It gets a result of eStateInvalid, and then marks the process as exited, but doesn't set "done" to true, so we go to fetch another event. That is not safe, since you don't know when that extra packet is going to arrive. If it arrives while you are tearing down the process, the internal-state-thread might try to handle it when the process in not in a good state. Rather than put more effort into checking all the shutdown paths to make sure this extra packet doesn't cause problems, just don't fetch it. We weren't going to do anything useful with it anyway. The main part of the patch is setting "done = true" when we get the eStateInvalid. I also added a check at the beginning of the while(done) loop to prevent another error from getting us to fetch packets for an exited process. I added a test case to ensure that if an Interrupt fails, we call the process exited. I can't test exactly the error I'm fixing, there's no good way to know that the stop reply for the failed interrupt wasn't fetched. But at least this asserts that the overall behavior is correct. Differential Revision: https://reviews.llvm.org/D101933 (cherry picked from commit 72ba78c)
We can end up with a call to `indexTopLevelDecl(D)` with `D == nullptr` in non-assert builds e.g. when indexing a module in `indexModule` and - `ASTReader::GetDecl` returns `nullptr` if `Index >= DeclsLoaded.size()`, thus returning `nullptr` => `ModuleDeclIterator::operator*` returns `nullptr` => we call `IndexCtx.indexTopLevelDecl` with `nullptr` Be resilient and just ignore the `nullptr` decls during indexing. Reviewed By: akyrtzi Differential Revision: https://reviews.llvm.org/D102001
…or-indexing [Index] Ignore nullptr decls for indexing
When SendContinuePacketAndWaitForResponse returns eStateInvalid, don'…
Revert the 32-process cap on Windows. When testing with Swift, we found that there was a time reduction for testing with the higher load. This should hopefully not matter much in practice. In the case that the original problem with python remains with a high subprocess count, we can easily revert this change. (cherry picked from commit d319005)
…a3302266b6ff7cf61be lit: revert 134b103
Since D87304, `align` become an invalid attribute on none pointer types and verifier will reject bitcode that has invalid `align` attribute. The problem is before the change, DeadArgumentElimination can easily turn a pointer return type into a void return type without removing `align` attribute. Teach Autograde to remove invalid `align` attribute from return types to maintain bitcode compatibility. rdar://77022993 Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D102201
(Cherry-picked from d65e5f6)
I think currently isImpliedViaMerge can incorrectly return true for phis in a loop/cycle, if the found condition involves the previous value of Consider the case in exit_cond_depends_on_inner_loop. At some point, we call (modulo simplifications) isImpliedViaMerge(<=, %x.lcssa, -1, %call, -1). The existing code tries to prove IncV <= -1 for all incoming values InvV using the found condition (%call <= -1). At the moment this succeeds, but only because it does not compare the same runtime value. The found condition checks the value of the last iteration, but the incoming value is from the *previous* iteration. Hence we incorrectly determine that the *previous* value was <= -1, which may not be true. I think we need to be more careful when looking at the incoming values here. In particular, we need to rule out that a found condition refers to any value that may refer to one of the previous iterations. I'm not sure there's a reliable way to do so (that also works of irreducible control flow). So for now this patch adds an additional requirement that the incoming value must properly dominate the phi block. This should ensure the values do not change in a cycle. I am not entirely sure if will catch all cases and I appreciate a through second look in that regard. Alternatively we could also unconditionally bail out in this case, instead of checking the incoming values Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D101829 (cherry-picked from 6c99e63)
…e file-cache is the amount requested. This change ensures that if for whatever reason we read less bytes than expected (for example, when trying to read memory that spans multiple sections), we try reading from the live process as well. Reviewed By: jasonmolenda Differential Revision: https://reviews.llvm.org/D101390 (cherry picked from commit 6c82b8a)
@swift-ci please 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.