Merge bastille into main #2252
Merged
Merge bastille into main #2252
+965
−285
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
The various GetSharedModule methods have an optional out parameter for the old module when a file has changed or been replaced, which the Target uses to keep its module list current/correct. We've been using a single ModuleSP to track "the" old module, and this change switches to using a SmallVector of ModuleSP, which has a couple benefits: - There are multiple codepaths which may discover an old module, and this centralizes the code for how to handle multiples in one place, in the Target code. With the single ModuleSP, each place that may discover an old module is responsible for how it handles multiples, and the current code is inconsistent (some code paths drop the first old module, others drop the second). - The API will be more natural for identifying old modules in routines that work on sets, like ModuleList::ReplaceEquivalent (which I plan on updating to report old module(s) in a subsequent change to fix a bug). I'm not convinced we can ever actually run into the case that multiple old modules are found in the same GetOrCreateModule call, but I think this change makes sense regardless, in light of the above. When an old module is reported, Target::GetOrCreateModule calls m_images.ReplaceModule, which doesn't allow multiple "old" modules; the new code calls ReplaceModule for the first "old" module, and for any subsequent old modules it logs the event and calls m_images.Remove. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89156 (cherry picked from commit 61bfc70)
This allows the Target to update its module list when loading a shared module replaces an equivalent one. A testcase is added which hits this codepath -- without the fix, the target reports libbreakpad.so twice in its module list. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D89157 (cherry picked from commit d20aa7c)
We unconditionally marked i64 as Custom, but did not install a handler in ReplaceNodeResults when i64 isn't legal type. This leads to ReplaceNodeResults asserting. We have two options to fix this. Only mark i64 as Custom on 64-bit targets and let it expand to two i32 bitreverses which each need a VPPERM. Or the other option is to add the Custom handling to ReplaceNodeResults. This is what I went with. (cherry picked from commit 57c0c4a)
…ate instantiation They can get stale at use time because of updates from other recursive specializations. Instead, rely on the existence of previous declarations to add the specialization. Differential Revision: https://reviews.llvm.org/D87853 (cherry picked from commit cffb0dd) This is a re-commit of 8ac7095 with some modifications to avoid changing the clang API.
The non-strict variants are already handled because they are canonicalized to strict variants by swapping hands in both the select and icmp, and the fold simply considers that strictness is irrelevant here. But that isn't actually true for the last pattern, as PR48390 reports. (cherry picked from commit f16320b)
… strict comparison (PR48390) We could create uadd.sat under incorrect circumstances if a select with -1 as the false value was canonicalized by swapping the T/F values. Unlike the other transforms in the same function, it is not invariant to equality. Some alive proofs: https://alive2.llvm.org/ce/z/emmKKL Based on original patch by David Green! Fixes https://bugs.llvm.org/show_bug.cgi?id=48390 Differential Revision: https://reviews.llvm.org/D92717 (cherry picked from commit e6f2a79)
GlobalAlias::getAliasee() may not always point directly to a GlobalVariable. In such cases, try to find the canonical GlobalVariable that the alias refers to. Link: ClangBuiltLinux/linux#1208 Reviewed By: dvyukov, nickdesaulniers Differential Revision: https://reviews.llvm.org/D92846 (cherry picked from commit c28b18a)
D73999 / commit 75af9da added for LLVM 11 a check that sh_flags and sh_entsize (and sh_type) changes are an error, in line with GNU assembler. However, GNU assembler accepts and GCC generates an abbreviated form: while the first .section contains the flags and entsize, subsequent sections simply contain the name without repeating entsize or flags. Do likewise for better compatibility. See https://bugs.llvm.org/show_bug.cgi?id=48201 Reviewed By: jhenderson, MaskRay Differential Revision: https://reviews.llvm.org/D92052 (cherry picked from commit 1deff40)
As reported in PR48177, the type-deduction extraction ends up going into an infinite loop when the type referred to has a recursive definition. This stops recursing and just substitutes the type-source-info the TypeLocBuilder identified when transforming the base. (cherry picked from commit 1c98f98)
Instead of relying on whether a certain identifier is a builtin, introduce BuiltinAttr to specify a declaration as having builtin semantics. This fixes incompatible redeclarations of builtins, as reverting the identifier as being builtin due to one incompatible redeclaration would have broken rest of the builtin calls. Mostly-compatible redeclarations of builtins also no longer have builtin semantics. They don't call the builtin nor inherit their attributes. A long-standing FIXME regarding builtins inside a namespace enclosed in extern "C" not being recognized is also addressed. Due to the more correct handling attributes for builtin functions are added in more places, resulting in more useful warnings. Tests are updated to reflect that. Intrinsics without an inline definition in intrin.h had `inline` and `static` removed as they had no effect and caused them to no longer be recognized as builtins otherwise. A pthread_create() related test is XFAIL-ed, as it relied on it being recognized as a builtin based on its name. The builtin declaration syntax is too restrictive and doesn't allow custom structs, function pointers, etc. It seems to be the only case and fixing this would require reworking the current builtin syntax, so this seems acceptable. Fixes PR45410. Reviewed By: rsmith, yutsumi Differential Revision: https://reviews.llvm.org/D77491
…bility objc_super is special and needs LookupPredefedObjCSuperType() called before performing builtin type comparisons. This fixes an error when compiling macOS headers. A test is added. Differential Revision: https://reviews.llvm.org/D87917
…red yet. This happens in glibc's headers. It's important that we recognize these functions so that we can mark them as returns_twice. Differential Revision: https://reviews.llvm.org/D88518
We now recognize this function as a builtin despite it having an unexpected number of parameters; make sure we don't enforce that it has only 1 argument for its 2 parameters.
This reverts commit abeec5d.
Revert commits that got automerged from the llvm.org 11.x release branch.
… overload This patch exposes the Target::CreateBreakpoint overload with the boolean argument to move to the neareast code to the SBAPI. This is useful when creating column breakpoints to restrict lldb's resolution to the pointed source location, preventing it to go to the next line. rdar://72196842 Differential Revision: https://reviews.llvm.org/D93266 Signed-off-by: Med Ismail Bennani <[email protected]>
[lldb/API] Expose Target::CreateBreakpoint(..., move_to_nearest_code)…
We currently do this for SANITIZER_IOS, which includes devices *and* simulators. This change opts out the check for simulators to unify the behavior with macOS, because VM size is really a property of the host OS, and not the simulator. <rdar://problem/72129387> Differential Revision: https://reviews.llvm.org/D93140
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset. Differential Revision: https://reviews.llvm.org/D91118 (cherry picked from commit bae9aed)
…in_unions_parsing_dwarf [LLDB] Fix handling of bit-fields in a union
|
@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.