| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
| |
"patchable-function-entry"="0"
Add improve tests
(cherry picked from commit d232c215669cb57f5eb4ead40a4a336220dbc429)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before addPreEmitPass()
This intention is to move patchable-function before aarch64-branch-targets
(configured in AArch64PassConfig::addPreEmitPass) so that we emit BTI before NOPs
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92424).
This also allows addPreEmitPass() passes to know the precise instruction sizes if they want.
Tried x86-64 Debug/Release builds of ccls with -fxray-instrument -fxray-instruction-threshold=1.
No output difference with this commit and the previous commit.
(cherry picked from commit 9a24488cb67a90f889529987275c5e411ce01dda)
|
|
|
|
|
|
| |
Otherwise they may be picked as the delay slot by mips-delay-slot-filler, if we move patchable-function before mips-delay-slot-filler.
(cherry picked from commit a72d15e37c5e066f597f13a8ba60aff214ac992d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The libcxx test suite auto-detects spaceship operator, but __config does not. This means that the libcxx test suite has been broken for over a month when using top-of-tree clang. This also really ought to be fixed before 10.0.
See: bc633a42dd409dbeb456263e3388b8caa4680aa0
Reviewers: chandlerc, mclow.lists, EricWF, ldionne, CaseyCarter
Reviewed By: EricWF
Subscribers: broadwaylamb, hans, dexonsmith, tstellar, llvm-commits, libcxx-commits
Tags: #libc, #llvm
Differential Revision: https://reviews.llvm.org/D72980
(cherry picked from commit 5dda92fcb0ce9206f831aa7cddf24421dcf044d7)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Unlike R_RISCV_RELAX, which is a linker hint, R_RISCV_ALIGN requires the
support of the linker even when ignoring all R_RISCV_RELAX relocations.
This is because the compiler emits as many NOPs as may be required for
the requested alignment, more than may be required pre-relaxation, to
allow for the target becoming more unaligned after relaxing earlier
sequences. This means that the target is often not initially aligned in
the object files, and so the R_RISCV_ALIGN relocations cannot just be
ignored. Since we do not support linker relaxation, we must turn these
into errors.
Reviewers: ruiu, MaskRay, espindola
Reviewed By: MaskRay
Subscribers: grimar, Jim, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71820
(cherry picked from commit d1da63664f4e42191daf2e6a9fa682ca9f75ef5e)
|
|
|
|
|
|
|
|
| |
Reviewed By: Bdragon28, jhenderson, grimar, sfertile
Differential Revision: https://reviews.llvm.org/D73255
(cherry picked from commit f1dab29908d25a4044abff6ffc120c48b20f034d)
|
|
|
|
|
|
|
| |
Concepts will be available with Clang 10 - update cxx_status.html to reflect
the papers that have been implemented.
(cherry picked from commit f394d22fa82df03eaf72bf1876e2d63bbe6cd00f)
|
|
|
|
|
|
| |
Concepts support has been ported to the 10.x release.
Add information about the feature to the release notes.
|
|
|
|
|
|
|
|
|
| |
As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become constant evaluated during satisfaction checking.
Change the evaluation context during parsing and instantiation of constraints to unevaluated.
(cherry picked from commit 73eaf62463b4a29adf4194685af12d1a5d172987)
|
|
|
|
|
|
|
|
|
| |
Now with concepts support merged and mostly complete, we do not need -fconcepts-ts
(which was also misleading as we were not implementing the TS) and can enable
concepts features under C++2a. A warning will be generated if users still attempt
to use -fconcepts-ts.
(cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters with constrained templates
Summary: Allow unconstrained template template parameters to accept constrainted templates as arguments.
Reviewers: rsmith
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73155
(cherry picked from commit d42d5eb8ea77b3a3a502a60ba3f053fb81a897f3)
|
|
|
|
|
|
|
| |
Proper ExpressionEvaluationContext were not being entered when instantiating constraint
expressions, which caused assertion failures in certain cases, including bug #44614.
(cherry picked from commit 4d33a8dfcf67e970ea4d150d514b27de02e79aee)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements P1141R2 "Yet another approach for constrained declarations".
General strategy for this patch was:
- Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints.
- Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic
previously used for generic lambdas, now unified with abbreviated templates, by:
- Tracking the template parameter lists in the Declarator object
- Tracking the template parameter depth before parsing function declarators (at which point we can match template
parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters
to or not).
- When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that
contain the info required to create and accumulate invented template parameters (fields that were already present in
LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context).
Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller.
Differential Revision: https://reviews.llvm.org/D65042
(cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
|
|
|
|
|
|
|
|
|
|
|
| |
Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish
between partial specializations which differ in their TemplateParameterList
type constraints.
Recommit, now profiling the IDC so that we can deal with situations where the
TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints).
(cherry picked from commit 62c221b5090c2e1d3ca408bcab6f69c4d9e175b7)
|
|
|
|
|
|
|
|
| |
function template requires clause
Fixes bug #44613 - incorrect instantiated parameters were being added when checking instantiated function constraints
(cherry picked from commit c2a250e1c43c05925fe040dc9624403af7879453)
|
|
|
|
|
|
|
| |
TryAnnotateTypeConstraint would not put the scope specifier back into the token stream when faced
with a non-concept name after a scope specifier.
(cherry picked from commit de51559fa68049da73b696a4e89468154b12852a)
|
|
|
|
|
|
| |
Remove inappropriate Sema include in ASTConcept.cpp introduced by D72552 for the finer-grained includes actually needed.
(cherry picked from commit bb9b964072eb42a09e76fe148b36eefcfff077b2)
|
|
|
|
|
|
|
|
|
|
|
| |
Add a simple cache for constraint satisfaction results. Whether or not this simple caching
would be permitted in final C++2a is currently being discussed but it is required for
acceptable performance so we use it in the meantime, with the possibility of adding some
cache invalidation mechanisms later.
Differential Revision: https://reviews.llvm.org/D72552
(cherry picked from commit b933d37cd3774e5431b35e82187eebb59b1ff59e)
|
|
|
|
|
|
|
|
|
| |
clang-tidy previously relied on there being no identifier for a TemplateTypeParmDecl for checking
whether 'decltype(x)' should be inserted, instead of checking whether or not it is implicit.
D65042 added new names for invented generic lambda template parameters, rendering that check incorrect.
(cherry picked from commit 5fdad8e3f803adce501ca25118f325184e54018d)
|
|
|
|
|
|
|
|
| |
D50360 caused some platforms to not compile due to a parameter with the name of a type.
Rename the parameter.
(cherry picked from commit e68c1e00eba4ae64d38e62eebebd581e3d3d6bd4)
|
|
|
|
|
|
|
|
|
|
| |
Implement support for C++2a requires-expressions.
Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.
Differential Revision: https://reviews.llvm.org/D50360
(cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A TemplateIdAnnotation represents only a template-id, not a
nested-name-specifier plus a template-id. Don't make a redundant copy of
the CXXScopeSpec and store it on the template-id annotation.
This slightly improves error recovery by more properly handling the case
where we would form an invalid CXXScopeSpec while parsing a typename
specifier, instead of accidentally putting the token stream into a
broken "annot_template_id with a scope specifier, but with no preceding
annot_cxxscope token" state.
(cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConceptSpecializationExprs (CSEs) were being created with nullptr
TemplateArgsAsWritten during TemplateTemplateParmDecl canonicalization, and
we were relying on them during profiling which caused sporadic crashes
in test/CXX/.../temp.arg.template/p3-2a.cpp introduced in D44352.
Change profiling of CSEs to instead rely on the actual converted template
arguments and concept named.
(cherry picked from commit 8a3446746098ba29348bb8f85357dd0b466a6d6e)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using the same strategy as c38e42527b21.
D69825 revealed (introduced?) a problem when building with ASan, and
some memory leaks somewhere. More details are available in the original
patch.
Looks like we missed one failing tests, this patch adds the workaround
to this test as well.
(cherry picked from commit e174da447c180b586719cb28f7bd556e30625762)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using in-process cc1, the Clang Interface Stubs pipeline setup
exposes an ASAN bug. I am still investigating this issue but want to
green the bots for now. I don't think this is a huge issue since the
Clang Interface Stubs Driver setup code is the only code path that sets
up such a pipeline (ie N cc1's for N c files followed by another N cc1's
for to generate stub files for the same N c files).
This issue is being discussed in https://reviews.llvm.org/D69825.
If a resolution is not found soon, a bugzilla filling will be in order.
(cherry picked from commit c38e42527b21acee8d01a016d5bfa2fb83202e29)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I felt really sad to push this commit for my selfish purpose to make
glibc -static-pie build with lld. Some code constructs in glibc require
R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX referencing undefined weak to
be resolved to a GOT entry not relocated by R_X86_64_GLOB_DAT (GNU ld
behavior), e.g.
csu/libc-start.c
if (__pthread_initialize_minimal != NULL)
__pthread_initialize_minimal ();
elf/dl-object.c
void
_dl_add_to_namespace_list (struct link_map *new, Lmid_t nsid)
{
/* We modify the list of loaded objects. */
__rtld_lock_lock_recursive (GL(dl_load_write_lock));
Emitting a GLOB_DAT will make the address equal &__ehdr_start (true
value) and cause elf/ldconfig to segfault. glibc really should move away
from weak references, which do not have defined semantics.
Temporarily special case --no-dynamic-linker.
(cherry picked from commit 0fbf28f7aae0ceb70071cac56de345e3ff04439c)
|
|
|
|
| |
-flax-vector-conversions on the Clang 10 release branch.
|
|
|
|
|
|
|
|
|
|
|
|
| |
-flax-vector-conversions=all to -flax-vector-conversions=integer."
This patch broke the Sanitizer buildbots. Please see the commit's
differential revision for more information
(https://reviews.llvm.org/D67678).
This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486.
(cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Wrange-loop-analysis issues a diagnostic on a dependent type in a
template the diagnostic may not be valid for all instantiations. Therefore
the diagnostic is suppressed during the instantiation. Non dependent types
still issue a diagnostic.
The same can happen when using macros. Therefore the diagnostic is
disabled for macros.
Fixes https://bugs.llvm.org/show_bug.cgi?id=44556
Differential Revision: https://reviews.llvm.org/D73007
(cherry picked from commit 41fcd17250fa0526e4b7fd2c7df7721b0f79b683)
|
|
|
|
| |
(cherry picked from commit ddfe8751b16a1d57b0586fb48d1109c98234bc3f)
|