| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
(cherry picked from commit 97d000da2e6025600c4709d611e853eb1d5d407c)
|
| |
|
|
| |
(cherry picked from commit b54aa053d3aeeab0cdaecb6286419138b7da5ef4)
|
| |
|
|
|
|
|
| |
This should fix the builders that were failing due to broken JIT examples
after ce2207abaf9.
(cherry picked from commit 98e55477558a823b1045b54d5a09681a3c0b819a)
|
| |
|
|
|
|
|
|
| |
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 e0a6093a744d16c90eafa62d7143ce41806b2466)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ce2207abaf9a925b35f15ef92aaff6b301ba6d22)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 84217ad66115cc31b184374a03c8333e4578996f)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 ab2300bc154f7bed43f85f74fd3fe31be71d90e0)
|
| |
|
|
|
|
|
|
|
|
|
| |
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 a2fb2c0ddca14c133f24d08af4a78b6a3d612ec6)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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) https://github.com/ClangBuiltLinux/linux/issues/773
Differential Revision: https://reviews.llvm.org/D73474
(cherry picked from commit 4f38ab250ff4680375c4c01db0a88c157093c665)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
|
| |
|
|
| |
(cherry picked from commit 31e07692d7f2b383bd64c63cd2b5c35b6503cf3a)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 55b0e9c9d5de7c5d70552ac9ca9ffc14097e983b)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 e11b709b1922ca46b443fcfa5d76b87edca48721)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 77cedb0cdb8623ff9eb22dbf3b9302ee4d9f8a20)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes https://github.com/clangd/clangd/issues/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 a31a61dafeaa9110687110fc127ea6f7c91dd3e6)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineFunction::getPSVManager()""
Reland 7a8b0b1595e7dc878b48cf9bbaa652087a6895db, 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 68051c122440b556e88a946bce12bae58fcfccb4)
(cherry picked from commit c7c5da6df30141c563e1f5b8ddeabeecdd29e55e)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This behavior appears to have changed unintentionally in
b0e979724f2679e4e6f5b824144ea89289bd6d56.
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 9521c18438a9f09663f3dc68aa7581371c0653c9)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 0cb274de397a193fb37c60653b336d48a3a4f1bd)
|
| |
|
|
|
|
|
| |
This reverts commit 7bc58a779aaa1de56fad8b1bc8e46932d2f2f1e4.
It breaks EXPENSIVE_CHECKS on Windows
(cherry picked from commit cef838e65f9a2aeecf5e19431077bc16b01a79fb)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: lenary, asb
Reviewed By: lenary
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72768
(cherry picked from commit 1256d68093ac1696034e385bbb4cb6e516b66bea)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: lenary, asb
Reviewed By: lenary
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72755
(cherry picked from commit e15fb06e2d0a068de549464d72081811e7fac612)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently 🡺 is used in hover response to represent return types, but it
is not widely available. Changing this back to original to support more clients.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73336
(cherry picked from commit 1b996faa1575bda6b99e778aaabe14834c10d3ff)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some names, e.g. constructor/destructor/conversions, already contain
the type info, no need to duplicate them in the hoverinfo.
Fixes https://github.com/clangd/clangd/issues/252
Reviewers: sammccall, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73110
(cherry picked from commit 1fbb1d6df0113ca341f6d257bc72e07343dd861a)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes https://github.com/clangd/clangd/issues/249
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72498
(cherry picked from commit 0474fe465d8feebcfd54a16d93ad8518b5625972)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently when hovering over an `auto` or `decltype` that resolve to a
builtin-type, clangd would display `<unknown>` as the kind of the symbol.
Drop that to make rendering nicer.
Reviewers: usaxena95
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72777
(cherry picked from commit b08e8353a89f682861ef947fdb6e229b3de2e37d)
|
| |
|
|
| |
(cherry picked from commit 041650da67051266eb92b5bb07223394fe1bdab1)
|
| |
|
|
| |
(cherry picked from commit 60adfb83cda883d9fc1079c89d2feaa681a41b90)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Moves type/returntype into its own line as it is more readable in cases
where the type is long.
Also gives parameter lists a heading, `Parameters:` to make them stand out.
Leaves the `right arrow` instead of `Returns: ` before Return Type to make
output more symmetric.
```
function foo
Returns: ret_type
Parameters:
- int x
```
vs
```
function foo
🡺 ret_type
Parameters:
- int x
```
Reviewers: sammccall, ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72623
(cherry picked from commit 44f9c7a820c1e5fb949f441214a46b13588ff51a)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72622
(cherry picked from commit d74a3d470c316f8fade90fe231fc0a51361c01e6)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This currently populates only the Name with the expression's type and
Value if expression is evaluatable.
Fixes https://github.com/clangd/clangd/issues/56
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72500
(cherry picked from commit 4d14bfaa2cb1610104db6b0818fc7d74fad1bd8f)
|
| |
|
|
|
|
|
|
|
| |
Long `cl::value_desc()` is added right after the flag name,
before `cl::desc()` column. And thus the `cl::desc()` column,
for all flags, is padded to the right,
which makes the output unreadable.
(cherry picked from commit 70cbf8c71c510077baadcad305fea6f62e830b06)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These instructions ignore parts of the input vectors which makes the
default MSan handling too strict and causes false positive reports.
Reviewers: vitalybuka, RKSimon, thakis
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73374
(cherry picked from commit 1df8549b26892198ddf77dfd627eb9f979d45b7e)
|
| |
|
|
|
|
|
| |
This fixes a "not a member of 'std'" error with e.g. Fedora 32.
Closes: #105
(cherry picked from commit 58592f6c49249293f79698cfcb31dba532e12603)
|
| |
|
|
|
|
|
|
| |
We ran into an assert when debugging clang and performing an expression on a class derived from DeclContext. The assert was indicating we were getting the offsets wrong for RecordDeclBitfields. We were getting both the size and offset of unnamed bit-field members wrong. We could fix this case with a quick change but as I extended the test suite to include more combinations we kept finding more cases that were being handled incorrectly. A fix that handled all the new cases as well as the cases already covered required a refactor of the existing technique.
Differential Revision: https://reviews.llvm.org/D72953
(cherry picked from commit fcaf5f6c01a09f23b948afb8c91c4dd951d4525e)
|
| |
|
|
| |
(cherry picked from commit 18e6a65bae93a7bf0e718415b394fe4b0f09221e)
|
| |
|
|
|
|
|
| |
The wrong set of TemplateArgs was being provided to addInstantiatedParametersToScope.
Caused bug #44658.
(cherry picked from commit 9c24fca2a33fc0fd059e278bb95c84803dfff9ae)
|
| |
|
|
|
|
| |
Caused bug 44671 when transforming a constructor with a type-constraint with no explicit template args.
(cherry picked from commit a8d096aff6b1930ad57bd0c30077d2b4920b5025)
|
| |
|
|
|
|
|
|
|
|
|
| |
tests for scope specifiers in type-constraints
The code for parsing of type-constraints in compound-requirements was not adapted for the new TryAnnotateTypeConstraint which
caused compound-requirements with scope specifiers to ignore them.
Also add regression tests for scope specifiers in type-constraints in more contexts.
(cherry picked from commit 5043962dd3150c6ac72b75174b9460a510d1b5c3)
|
| |
|
|
|
|
| |
MIPS specific part of LLVM 10.0 Release notes for LLVM, Clang and LLD.
Differential Revision: https://reviews.llvm.org/D73108
|
| |
|
|
|
|
|
|
|
|
|
| |
* Generalize the code added in D70637 and D70937. We should eventually remove the EM_MIPS special case.
* Handle R_PPC_LOCAL24PC the same way as R_PPC_REL24.
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D73424
(cherry picked from commit 70389be7a029bec3c45991a60b627445ef996120)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fno-pie produces a pair of non-GOT-non-PLT relocations R_PPC_ADDR16_{HA,LO} (R_ABS) referencing external
functions.
```
lis 3, func@ha
la 3, func@l(3)
```
In a -no-pie/-pie link, if func is not defined in the executable, a canonical PLT entry (st_value>0, st_shndx=0) will be needed.
References to func in shared objects will be resolved to this address.
-fno-pie -pie should fail with "can't create dynamic relocation ... against ...", so we just need to think about -no-pie.
On x86, the PLT entry passes the JMP_SLOT offset to the rtld PLT resolver.
On x86-64: the PLT entry passes the JUMP_SLOT index to the rtld PLT resolver.
On ARM/AArch64: the PLT entry passes &.got.plt[n]. The PLT header passes &.got.plt[fixed-index]. The rtld PLT resolver can compute the JUMP_SLOT index from the two addresses.
For these targets, the canonical PLT entry can just reuse the regular PLT entry (in PltSection).
On PPC32: PltSection (.glink) consists of `b PLTresolve` instructions and `PLTresolve`. The rtld PLT resolver depends on r11 having been set up to the .plt (GotPltSection) entry.
On PPC64 ELFv2: PltSection (.glink) consists of `__glink_PLTresolve` and `bl __glink_PLTresolve`. The rtld PLT resolver depends on r12 having been set up to the .plt (GotPltSection) entry.
We cannot reuse a `b PLTresolve`/`bl __glink_PLTresolve` in PltSection as a canonical PLT entry. PPC64 ELFv2 avoids the problem by using TOC for any external reference, even in non-pic code, so the canonical PLT entry scenario should not happen in the first place.
For PPC32, we have to create a PLT call stub as the canonical PLT entry. The code sequence sets up r11.
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D73399
(cherry picked from commit 837e8a9c0cd097034e023dfba146d17ce132998c)
|
| |
|
|
|
|
|
|
|
|
| |
We would previously try to evaluate atomic constraints of non-template functions as-is,
and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656).
Substitute into atomic constraints of non-template functions as we would atomic constraints
of template functions, in order to rebuild the expressions in a constant-evaluated context.
(cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
|
| |
|
|
|
|
| |
Wrong argument order resulted in broken shfl ops for 64-bit types.
(cherry picked from commit cc14de88da27a8178976972bdc8211c31f7ca9ae)
|
| |
|
|
|
|
|
|
| |
instead of -start-after=patchable-function
To break order dependency between livedebugvalues and patchable-function.
(cherry picked from commit 26ba1f77b55e7a961acc05d94bfa4b677a9e5d83)
|
| |
|
|
|
|
| |
Member functions will have the thiscall attribute on them.
(cherry picked from commit 698d1cd3b8154b3b74423386d3e111e6b756e87a)
|
| |
|
|
|
|
|
|
|
|
| |
This fixed build failures due to missing ompt headers.
See https://bugs.gentoo.org/700762.
Differential Revision: https://reviews.llvm.org/D73249
(cherry picked from commit 3c545e4b7318c337bed43d5bc76aad040565f1ef)
|
| |
|
|
|
|
|
|
| |
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D73301
(cherry picked from commit 50a3ff30e1587235d1830fec9694c1239302ab9f)
|
| |
|
|
|
|
|
|
|
|
| |
__attribute__((patchable_function_entry(N,M))) where M>0
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D73072
(cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
|
| |
|
|
|
|
|
|
|
|
| |
interaction with -fcf-protection=branch
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D73071
(cherry picked from commit 01da05b71aa72c15a518d3407682a3775db63808)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fpatchable-function-entry=N,M where M>0
Similar to the function attribute `prefix` (prefix data),
"patchable-function-prefix" inserts data (M NOPs) before the function
entry label.
-fpatchable-function-entry=2,1 (1 NOP before entry, 1 NOP after entry)
will look like:
```
.type foo,@function
.Ltmp0: # @foo
nop
foo:
.Lfunc_begin0:
# optional `bti c` (AArch64 Branch Target Identification) or
# `endbr64` (Intel Indirect Branch Tracking)
nop
.section __patchable_function_entries,"awo",@progbits,get,unique,0
.p2align 3
.quad .Ltmp0
```
-fpatchable-function-entry=N,0 + -mbranch-protection=bti/-fcf-protection=branch has two reasonable
placements (https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01185.html):
```
(a) (b)
func: func:
.Ltmp0: bti c
bti c .Ltmp0:
nop nop
```
(a) needs no additional code. If the consensus is to go for (b), we will
need more code in AArch64BranchTargets.cpp / X86IndirectBranchTracking.cpp .
Differential Revision: https://reviews.llvm.org/D73070
(cherry picked from commit 22467e259507f5ead2a87d989251b4c951a587e4)
|