| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This reverts commit r303497 since it breaks the msan bootstrap bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1379/
llvm-svn: 303498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes the split between the "exact" backedge taken count
and the "maximum" backedge taken count a bit more obvious. Both of
these are upper bounds on the number of times the loop header
executes (since SCEV does not account for most kinds of abnormal
control flow), but the latter is guaranteed to be a constant.
There were a few places where the max backedge taken count *was* a
non-constant; I've changed those to compute constants instead.
At this point, I'm not sure if the constant max backedge count can be
computed by calling `getUnsignedRange(Exact).getUnsignedMax()` without
losing precision. If it can, we can simplify even further by making
`getMaxBackedgeTakenCount` a thin wrapper around
`getBackedgeTakenCount` and `getUnsignedRange`.
llvm-svn: 303497
|
| |
|
|
|
|
|
|
| |
This reverts commit 143d7445b5dfa2f6d6c45bdbe0433d9fc531be21.
Build breaking
llvm-svn: 303496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This allows pthread_self to be pulled out of a loop by LICM.
Reviewers: hfinkel, arsenm, davide
Reviewed By: davide
Subscribers: davide, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D32782
llvm-svn: 303495
|
| |
|
|
|
|
|
| |
This should appease the lld build bot regression
Following up on rL303493
llvm-svn: 303494
|
| |
|
|
|
|
|
| |
This should appease the lld build bot regression
Intrroduced by rL303490
llvm-svn: 303493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)
Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.
For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}
See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627
In summary (and reiteration), the fix is as follows:
- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.
See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.
Thanks Richard!
llvm-svn: 303492
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is split up into two commits.
This commit removes the DEF parser from LLD
See the previous commit for the creation in LLVM.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D32689
llvm-svn: 303491
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is split up into two commits.
The will create the DEF parser in LLVM.
Check the following commit to see the removal from LLD
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D32689
llvm-svn: 303490
|
| |
|
|
| |
llvm-svn: 303489
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
To not break LTO with different optimizations levels, we should insert
the barrier regardles of optimization level.
Reviewers: rjmccall, rsmith, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D32401
llvm-svn: 303488
|
| |
|
|
|
|
|
| |
Fixed "most platform" to read "most platforms", and changed "are not
using the same" to "use different" as a drive-by.
llvm-svn: 303487
|
| |
|
|
| |
llvm-svn: 303486
|
| |
|
|
|
|
|
|
| |
A test case with a GPU runline was added without setting 'REQUIRES=pollyacc'. We
drop the GPU run line, as the basic functionality can already be tested with
the normal code generation.
llvm-svn: 303485
|
| |
|
|
|
|
|
|
|
| |
source symbols
Patch by Nathan Hawes.
https://reviews.llvm.org/D33346
llvm-svn: 303484
|
| |
|
|
|
|
| |
sizeof expressions, in favor of constants containing the size directly
llvm-svn: 303483
|
| |
|
|
| |
llvm-svn: 303482
|
| |
|
|
|
|
|
|
| |
Failed libFuzzer tests on Windows.
This reverts commit r303476.
llvm-svn: 303481
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary: Added the new modules in the Object/ folder. Updated the
llvm-cvtres interface as well, and added additional tests.
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33180
llvm-svn: 303480
|
| |
|
|
|
|
|
| |
describe what they're for, not how they do it, and factor out a bit more
common code into them.
llvm-svn: 303479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-commit r303463 now that LLVM is fixed and adjust some lit tests.
llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.
Differential Revision: https://reviews.llvm.org/D32982
llvm-svn: 303478
|
| |
|
|
|
|
|
| |
- Improve wchar_t size predicitions based on target triple.
- Be less strict in wchar_t size verifier.
llvm-svn: 303477
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: srhines, kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D32443
llvm-svn: 303476
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where we have an operand defined by a lod of the
same memory location. Historically this was a VariableExpression
because we wanted to make sure they ended up in the same class,
but if we create the right expression, they end up in the same
class anyway.
Fixes PR32897. Thanks to Dan for the detailed discussion and the
fix suggestion.
llvm-svn: 303475
|
| |
|
|
|
|
|
|
|
| |
Let's revert this for now (and with it the assert()) to get the bots
back to green until I have LLVM synced up properly.
This reverts commit r303463.
llvm-svn: 303474
|
| |
|
|
|
|
|
|
|
|
| |
This was here because we don't want to switch leaders too much,
in order to avoid fixpoint(ing) issue, but it's not sure if it
matters in practice.
A first step towards fixing PR32897.
llvm-svn: 303473
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The trial parse for declarative syntax accepts an invalid pack
declaration syntax, which is ambiguous with valid pack expansions of
expressions. This commit removes the invalid pack declaration syntax to
avoid mistaking valid pack expansions as invalid declarator components.
Additionally, the trial parse of a //template-argument-list// then needs
to handle the optional ellipsis that is part of that grammar, as opposed
to relying on the trial parse for declarators accepting stray ellipses.
Reviewers: rsmith, rcraik, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33339
llvm-svn: 303472
|
| |
|
|
|
|
| |
avoid ambiguous 'else' [-Wdangling-else].
llvm-svn: 303471
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ThinLTOCodeGenerator.""
This reapplies commit r303438 modified to not verify cross-imported
bitcode in FunctionImporter.
rdar://problem/31233625
Differential Revision: https://reviews.llvm.org/D33370
llvm-svn: 303470
|
| |
|
|
|
|
|
|
|
| |
remove the mechanism for doing so.
This mechanism was incorrect in the presence of preprocessed modules (and
#pragma clang module begin/end).
llvm-svn: 303469
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reaching the end of a module, we used to convert its macros to
ModuleMacros but also leave them in the MacroDirective chain for the
identifier. This meant that every lookup of such a macro would find two
(identical) definitions. It also made it difficult to determine the correct
owner for a macro when reaching the end of a module: the most recent
MacroDirective in the chain could be from an #included submodule rather than
the current module.
Simplify this: whenever we convert a MacroDirective to a ModuleMacro when
leaving a module, clear out the MacroDirective chain for that identifier, and
just rely on the ModuleMacro to provide the macro definition information.
(We don't want to do this for local submodule visibility mode, because in that
mode we maintain a distinct MacroDirective chain for each submodule, and we
need to keep around the prior MacroDirective in case we re-enter the submodule
-- for instance, if its header is #included more than once in a module build,
we need the include guard directive to stick around. But the problem doesn't
arise in this case for the same reason: each submodule has its own
MacroDirective chain, so the macros don't leak out of submodules in the first
place.)
This reinstates r302932, reverted in r302947, with a fix for a bug that
resulted in us sometimes losing macro definitions due to failing to clear out
the overridden module macro list when promoting a directive to a module macro.
llvm-svn: 303468
|
| |
|
|
|
|
| |
This reverts commit r303438 while deliberating buildbot breakage.
llvm-svn: 303467
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D33049
llvm-svn: 303466
|
| |
|
|
|
|
|
| |
find the python headers when buiding crashinfo.c
<rdar://problem/32288076>
llvm-svn: 303465
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: We are going to make it tri-state and remove allow_user_segv_handler.
Reviewers: eugenis, alekseys, kcc
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33159
llvm-svn: 303464
|
| |
|
|
|
|
|
|
|
|
|
|
| |
llvm::TargetLibraryInfo needs to know the size of wchar_t to work on
functions like `wcslen`. This patch changes clang to always emit the
wchar_size module flag (it would only do so for ARM previously).
This also adds an `assert()` to ensure the LLVM defaults based on the
target triple are in sync with clang.
Differential Revision: https://reviews.llvm.org/D32982
llvm-svn: 303463
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis, alekseyshl
Subscribers: kubamracek, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D33344
llvm-svn: 303462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the strlen optimization code to work for both strlen and wcslen.
This especially helps with programs in the wild where people pass
L"string"s to const std::wstring& function parameters and the wstring
constructor gets inlined.
This also fixes a lingerind API problem/bug in getConstantStringInfo()
where zeroinitializers would always give you an empty string (without a
length) back regardless of the actual length of the initializer which
did not work well in the TrimAtNul==false causing the PR mentioned
below.
Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG
memcpy lowering and may lead to some cases for out-of-bounds
zeroinitializer accesses not getting optimized anymore. So some code
with UB may produce out of bound memory reads now instead of just
producing zeros.
The refactoring "accidentally" fixes http://llvm.org/PR32124
Differential Revision: https://reviews.llvm.org/D32839
llvm-svn: 303461
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32974
llvm-svn: 303460
|
| |
|
|
|
|
|
| |
r303450
[ODRHash] Support TemplateName and TemplateArgument
llvm-svn: 303459
|
| |
|
|
|
|
|
|
|
|
| |
getParamAlignment expects an argument number, not an AttributeList
index.
Johan Englan, who works on LDC, found this bug and told me about it off
list.
llvm-svn: 303458
|
| |
|
|
| |
llvm-svn: 303457
|
| |
|
|
|
|
| |
Workaround for apparent miscompilation of PR32143.
llvm-svn: 303456
|
| |
|
|
| |
llvm-svn: 303454
|
| |
|
|
|
|
|
|
|
|
| |
This is a complicated bug involving two issues:
1. What do we do with phi nodes when we prove all arguments are not
live?
2. When is it safe to use value leaders to determine if we can ignore
an argumnet?
llvm-svn: 303453
|
| |
|
|
| |
llvm-svn: 303452
|
| |
|
|
|
|
| |
written as pointer types.
llvm-svn: 303451
|
| |
|
|
| |
llvm-svn: 303450
|
| |
|
|
| |
llvm-svn: 303448
|
| |
|
|
|
|
| |
Clarify a comment while I'm here.
llvm-svn: 303447
|