-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Trojan #248
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
Closed
Closed
Trojan #248
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
1. if users don't specific -mattr, the default target-feature come from IR attribute. 2. fixed bug and re-land this patch Reviewers: lenary, asb Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70837 (cherry picked from commit 0cb274d)
This behavior appears to have changed unintentionally in b0e9797. Instead of printing the leading newline in printFunction, print it when printing a module. This ensures that `OS << *Func` starts printing immediately on the current line, but whole modules are printed nicely. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D73505 (cherry picked from commit 9521c18)
…hineFunction::getPSVManager()"" Reland 7a8b0b1, with a fix that checks `!E.value().empty()` to avoid inserting a zero to SlotRemap. Debugged by rnk@ in https://bugs.chromium.org/p/chromium/issues/detail?id=1045650#c33 Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D73510 (cherry picked from commit 68051c1) (cherry picked from commit c7c5da6)
Summary: Fixes clangd/clangd#263 Reviewers: hokein, sammccall Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73344 (cherry picked from commit a31a61d)
The test was printing a char[3] variable without a terminating nul. The memory after that variable (an unnamed bitfield) was not initialized. If the memory happened to be nonzero, the summary provider for the variable would run off into the next field. This is probably not the right behavior (it should stop at the end of the array), but this is not the purpose of this test. I have filed pr44649 for this bug, and fixed the test to not depend on this behavior. (cherry picked from commit 77cedb0)
Similar to R_MIPS_GPREL16 and R_MIPS_GPREL32 (D45972). If the addend of an R_PPC_PLTREL24 is >= 0x8000, it indicates that r30 is relative to the input section .got2. ``` addis 30, 30, .got2+0x8000-.L1$pb@ha addi 30, 30, .got2+0x8000-.L1$pb@l ... bl foo+0x8000@PLT ``` After linking, the relocation will be relative to the output section .got2. To compensate for the shift `address(input section .got2) - address(output section .got2) = ppc32Got2OutSecOff`, adjust by `ppc32Got2OutSecOff`: ``` addis 30, 30, .got2+0x8000-.L1+ppc32Got2OutSecOff$pb@ha addi 30, 30, .got2+0x8000-.L1+ppc32Got2OutSecOff$pb@ha$pb@l ... bl foo+0x8000+ppc32Got2OutSecOff@PLT ``` This rule applys to a relocatable link or a non-relocatable link with --emit-relocs. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73532 (cherry picked from commit e11b709)
Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=44696 Reviewers: sammccall Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73613 (cherry picked from commit 55b0e9c)
(cherry picked from commit 31e0769)
… one. This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefee)
…mbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) ClangBuiltLinux/linux#773 Differential Revision: https://reviews.llvm.org/D73474 (cherry picked from commit 4f38ab2)
Symbols created for merged external global variables have default visibility. This can break programs when compiling with -Oz -fvisibility=hidden as symbols that should be hidden will be exported at link time. Differential Revision: https://reviews.llvm.org/D73235 (cherry picked from commit a2fb2c0)
This commit fixes PR39321. GlobalExtensions is not guaranteed to be destroyed when optimizer plugins are unloaded. If it is indeed destroyed after a plugin is dlclose-d, the destructor of the corresponding ExtensionFn is not mapped anymore, causing a call to unmapped memory during destruction. This commit guarantees that extensions coming from external plugins are removed from GlobalExtensions when the plugin is unloaded if GlobalExtensions has not been destroyed yet. Differential Revision: https://reviews.llvm.org/D71959 (cherry picked from commit ab2300b)
The MaterializationResponsibility::defineMaterializing method allows clients to add new definitions that are in the process of being materialized to the JIT. This patch adds support to defineMaterializing for symbols with weak linkage where the new definitions may be rejected if another materializer concurrently defines the same symbol. If a weak symbol is rejected it will not be added to the MaterializationResponsibility's responsibility set. Clients can check for membership in the responsibility set via the MaterializationResponsibility::getSymbols() method before resolving any such weak symbols. This patch also adds code to RTDyldObjectLinkingLayer to tag COFF comdat symbols introduced during codegen as weak, on the assumption that these are COFF comdat constants. This fixes http://llvm.org/PR40074. (cherry picked from commit 84217ad)
This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The ManglingOptions struct defines the emulated-TLS state (via a bool member, EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the CompileFunction typedef used to), but adds a method to return the IRCompileLayer::ManglingOptions that the compiler will use. These changes allow us to correctly determine the symbols that will be produced when a thread local global variable defined at the IR level is compiled with or without emulated TLS. This is required for ORCv2, where MaterializationUnits must declare their interface up-front. Most ORCv2 clients should not require any changes. Clients writing custom IR compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler, rather than an IRCompileLayer::CompileFunction, however this should be a straightforward change (see modifications to CompileUtils.* in this patch for an example). (cherry picked from commit ce2207a)
This should fix the build failure at http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/32524 and others. (cherry picked from commit e0a6093)
(cherry picked from commit b54aa05)
. (cherry picked from commit 97d000d)
Summary: D72308 incorrectly assumed `resume` cannot exist without a `landingpad`, which is not true. This sets `Changed` to true whenever we make changes to a function, including creating a call to `__resumeException` within a function without a landing pad. Reviewers: tlively Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73308 (cherry picked from commit 580d783)
The checker bugprone-infinite-loop does not track changes of variables in the initialization expression of a variable declared inside the condition of the while statement. This leads to false positives, similarly to the one in the bug report https://bugs.llvm.org/show_bug.cgi?id=44618. This patch fixes this issue by enabling tracking of the variables of this expression as well. Differential Revision: https://reviews.llvm.org/D73270 (cherry picked from commit 70f4c6e)
Dead instructions do not need to be sunk. Currently we try and record the recipies for them, but there are no recipes emitted for them and there's nothing to sink. They can be removed from SinkAfter while marking them for recording. Fixes PR44634. Reviewers: rengolin, hsaito, fhahn, Ayal, gilr Reviewed By: gilr Differential Revision: https://reviews.llvm.org/D73423 (cherry picked from commit a911fef)
…git checkout Summary: Previously we mmapped on unix and not on windows: on windows mmap takes an exclusive lock on the file and prevents the user saving changes! The failure mode on linux is a bit more subtle: if the file is changed on disk but the SourceManager sticks around, then subsequent operations on the SourceManager will fail as invariants are violated (e.g. null-termination). This commonly manifests as crashes after switching git branches with many files open in clangd. Nominally mmap is for performance here, and we should be willing to give some up to stop crashing. Measurements on my system (linux+desktop+SSD) at least show no measurable regression on an a fairly IO-heavy workload: drop disk caches, open SemaOverload.cpp, wait for first diagnostics. for i in `seq 100`; do for variant in mmap volatile; do echo 3 | sudo tee /proc/sys/vm/drop_caches /usr/bin/time --append --quiet -o ~/timings -f "%C %E" \ bin/clangd.$variant -sync -background-index=0 < /tmp/mirror > /dev/null done done bin/clangd.mmap -sync -background-index=0 0:07.60 bin/clangd.volatile -sync -background-index=0 0:07.89 bin/clangd.mmap -sync -background-index=0 0:07.44 bin/clangd.volatile -sync -background-index=0 0:07.89 bin/clangd.mmap -sync -background-index=0 0:07.42 bin/clangd.volatile -sync -background-index=0 0:07.50 bin/clangd.mmap -sync -background-index=0 0:07.90 bin/clangd.volatile -sync -background-index=0 0:07.53 bin/clangd.mmap -sync -background-index=0 0:07.64 bin/clangd.volatile -sync -background-index=0 0:07.55 bin/clangd.mmap -sync -background-index=0 0:07.75 bin/clangd.volatile -sync -background-index=0 0:07.47 bin/clangd.mmap -sync -background-index=0 0:07.90 bin/clangd.volatile -sync -background-index=0 0:07.50 bin/clangd.mmap -sync -background-index=0 0:07.81 bin/clangd.volatile -sync -background-index=0 0:07.95 bin/clangd.mmap -sync -background-index=0 0:07.55 bin/clangd.volatile -sync -background-index=0 0:07.65 bin/clangd.mmap -sync -background-index=0 0:08.15 bin/clangd.volatile -sync -background-index=0 0:07.54 bin/clangd.mmap -sync -background-index=0 0:07.78 bin/clangd.volatile -sync -background-index=0 0:07.61 bin/clangd.mmap -sync -background-index=0 0:07.78 bin/clangd.volatile -sync -background-index=0 0:07.55 bin/clangd.mmap -sync -background-index=0 0:07.41 bin/clangd.volatile -sync -background-index=0 0:07.40 bin/clangd.mmap -sync -background-index=0 0:07.54 bin/clangd.volatile -sync -background-index=0 0:07.42 bin/clangd.mmap -sync -background-index=0 0:07.45 bin/clangd.volatile -sync -background-index=0 0:07.49 bin/clangd.mmap -sync -background-index=0 0:07.95 bin/clangd.volatile -sync -background-index=0 0:07.66 bin/clangd.mmap -sync -background-index=0 0:08.04 Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73617 (cherry picked from commit b500c49)
…itions" ... as well as: Revert "[DWARF] Defer creating declaration DIEs until we prepare call site info" This reverts commit fa4701e. This reverts commit 79daafc. There have been reports of this assert getting hit: CalleeDIE && "Could not find DIE for call site entry origin (cherry picked from commit 802bec8)
Changes to ORC in ce2207a changed the APIs in IRCompileLayer, now requiring the custom compiler to be wrapped in IRCompileLayer::IRCompiler. Even though MLIR relies on Orc CompileUtils, the type is still visible in several places in the code. Adapt those to the new API. (cherry picked from commit 7984b47)
(cherry picked from commit ef465d0)
Because it's in the AArch64/ directory, it runs in cases where the arm target may not be available, see comment on D73235. (cherry picked from commit 6be9acd)
Summary: FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but the C++ version check in its system headers was written incorrectly. This has now been fixed for both FreeBSD 13 and 12. Add checks for the corresponding `__FreeBSD_version` values, to define `_LIBCPP_HAS_TIMESPEC_GET` when the function is supported. Reviewers: emaste, EricWF, ldionne, mclow.lists Reviewed By: ldionne Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71522 (cherry picked from commit 5e416ba)
bin/clang-tblgen -gen-diag-docs -I../clang/include \ -I../clang/include/clang/Basic/ \ ../clang/include/clang/Basic/Diagnostic.td -o \ ../clang/docs/DiagnosticsReference.rst && \ bin/clang-tblgen -gen-attr-docs -I../clang/include \ ../clang/include/clang/Basic/Attr.td -o \ ../clang/docs/AttributeReference.rst && \ bin/clang-tblgen -gen-opt-docs -I../clang/include \ -I../clang/include/clang/Driver -I../llvm/include \ ../clang/include/clang/Driver/ClangOptionDocs.td -o \ ../clang/docs/ClangCommandLineReference.rst
We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9be)
FoundDecl was missing from ConceptSpecializationExpr serialization - add it. (cherry picked from commit f9e6389)
isSameEntity was missing constraints checking, causing constrained overloads to not travel well accross serialization. (bug llvm#45115) Add constraints checking to isSameEntity. (cherry picked from commit 7fb562c)
deduction guides. Previously if an implicit deduction guide had a default argument with a cleanup, we'd leave the 'pending cleanup' flag set after declaring the implicit guide. But it turns out that there's no reason to even substitute into the default argument when declaring an implicit deduction guide: we only need to record that the default argument exists, not what it is, since we never actually form a call to a deduction guide. (cherry picked from commit 6d894af)
a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1)
…r a compiler crash After a crash catched by the CrashRecoveryContext, this patch prevents from accessing dangling pointers in TimerGroup structures before the clang tool exits. Previously, the default TimerGroup had internal linked lists which were still pointing to old Timer or TimerGroup instances, which lived in stack frames released by the CrashRecoveryContext. Fixes PR45164. Differential Revision: https://reviews.llvm.org/D76099 (cherry picked from commit 28ad9fc)
…Decl We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect handling of 'this' inside RequiresExprBodyDecls (bug llvm#45162). Assign the current context as the DeclContext of the transformed decl. (cherry picked from commit 9769e1e)
…annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc5)
…straint annotates an invalid template-id" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 135744c.
…ExprBodyDecl" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 9e0bd5e.
Test that instcombine and early-cse can cooperate to reduce sequences of select patterns that are not composed of the same underlying instructions. There's a bug in EarlyCSE (PR41083), and we can test how much a possible fix (D74285) may affect optimization. (cherry picked from commit 0ad6e72)
As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags. ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE. Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs: /// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely. (And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines. I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk. Differential Revision: https://reviews.llvm.org/D74285 (cherry picked from commit b8ebc11)
…/Transforms/PhaseOrdering/min-max-abs-cse.ll
…Decl We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect handling of 'this' inside RequiresExprBodyDecls (bug llvm#45162). Assign the current context as the DeclContext of the transformed decl. (cherry picked from commit 9769e1e)
…annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc5)
This fixes an issue with clang issuing a warning about unknown CUDA SDK if it's detected during non-CUDA compilation. Differential Revision: https://reviews.llvm.org/D76030 (cherry picked from commit eb2ba2e)
This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.