| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TemplateSpecializationType doesn't quite have getDecl(). Need to go
through TemplateName to get a TemplateDecl.
Added test cases for the hasDeclaration() overload for
TemplateSpecializationType. Also introduced the type matcher
templateSpecializationType() used by the new hasDeclaration() test case.
Updated LibASTMatchersReference.
Reviewers: klimek
llvm-svn: 176025
|
|
|
|
|
|
|
|
|
|
|
| |
Re-introducing r175532. The has_getDecl metafunction didn't compile with
Visual Studio. This revision uses approaches has_getDecl from a
different angle that isn't a problem for Visual Studio.
Added dedicated tests for the metafunction.
Reviewers: klimek
llvm-svn: 176024
|
|
|
|
| |
llvm-svn: 176023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory intrinsics in the SDAG builder.
When alignment is zero, the lang ref says that *no* alignment
assumptions can be made. This is the exact opposite of the internal API
contracts of the DAG where alignment 0 indicates that the alignment can
be made to be anything desired.
There is another, more explicit alignment that is better suited for the
role of "no alignment at all": an alignment of 1. Map the intrinsic
alignment to this early so that we don't end up generating aligned DAGs.
It is really terrifying that we've never seen this before, but we
suddenly started generating a large number of alignment 0 memcpys due to
the new code to do memcpy-based copying of POD class members. That patch
contains a bug that rounds bitfield alignments down when they are the
first field. This can in turn produce zero alignments.
This fixes weird crashes I've seen in library users of LLVM on 32-bit
hosts, etc.
llvm-svn: 176022
|
|
|
|
| |
llvm-svn: 176021
|
|
|
|
| |
llvm-svn: 176020
|
|
|
|
|
|
|
|
|
|
|
| |
Re-introducing r175532. The has_getDecl metafunction didn't compile with Visual
Studio. This revision approaches has_getDecl from a different angle that isn't
a problem for Visual Studio.
Added dedicated tests for the metafunction.
Reviewers: klimek
llvm-svn: 176019
|
|
|
|
| |
llvm-svn: 176018
|
|
|
|
|
|
|
| |
Also, add matchers isPrivate(), isProtected() and isPublic(), that
restrict the matching of such AccessSpecDecls and all other Decls.
llvm-svn: 176017
|
|
|
|
|
|
| |
sanitizer_stacktrace_test. Build sanitizer_common tests with -Werror as we use predictable just-built Clang for building them
llvm-svn: 176014
|
|
|
|
| |
llvm-svn: 176013
|
|
|
|
| |
llvm-svn: 176012
|
|
|
|
|
|
|
|
|
|
|
|
| |
looking for is always a VarRegion.
This was triggering assertion failures when analyzing the LLVM codebase. This
is fallout from r175988.
I've got delta chewing away on a test case, but I wanted the fix to go
in now.
llvm-svn: 176011
|
|
|
|
|
|
|
|
|
|
| |
ExplodedNode pruning.
r175988 modified the ExplodedGraph trimming algorithm to retain all
nodes for "lvalue" expressions. This patch refines that notion to
only "interesting" expressions that would be used for diagnostics.
llvm-svn: 176010
|
|
|
|
|
|
|
| |
This is an ongoing process. Any command line option which a back-end cares about
should be added here.
llvm-svn: 176009
|
|
|
|
|
|
| |
Need available CPU on target device to support CPU reporting.
llvm-svn: 176008
|
|
|
|
| |
llvm-svn: 176007
|
|
|
|
| |
llvm-svn: 176005
|
|
|
|
| |
llvm-svn: 176004
|
|
|
|
| |
llvm-svn: 176003
|
|
|
|
| |
llvm-svn: 176002
|
|
|
|
|
|
| |
capitalization, as suggested by Chandler.
llvm-svn: 176001
|
|
|
|
| |
llvm-svn: 176000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR14967 and is generall necessary to avoid
situations where the column limit is exceeded. The challenge is
restricting such lines splits, otherwise clang-format suddenly starts
breaking at bad places.
Before:
ReallyLongReturnType<TemplateParam1, TemplateParam2>
ReallyReallyLongFunctionName(
const std::string &SomeParameter,
const SomeType<string,
SomeOtherTemplateParameter> &ReallyReallyLongParameterName,
const SomeType<string,
SomeOtherTemplateParameter> &AnotherLongParameterName) {}
After:
ReallyLongReturnType<TemplateParam1, TemplateParam2>
ReallyReallyLongFunctionName(
const std::string &SomeParameter,
const SomeType<string, SomeOtherTemplateParameter> &
ReallyReallyLongParameterName,
const SomeType<string, SomeOtherTemplateParameter> &
AnotherLongParameterName) {}
llvm-svn: 175999
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a const_cast hack from PPCRegisterInfo::hasReservedSpillSlot().
The proper place to save the frame index for the CR spill slot is in the
PPCFunctionInfo object, not the PPCRegisterInfo object.
No new test cases, as this just reimplements existing function. Existing
tests such as test/CodeGen/PowerPC/crsave.ll are sufficient.
llvm-svn: 175998
|
|
|
|
| |
llvm-svn: 175997
|
|
|
|
|
|
| |
The error is a bit strange tbh, but better than crashing.
llvm-svn: 175996
|
|
|
|
|
|
|
|
|
|
| |
This is a common pattern with dyn_cast and similar constructs, when the
PHI no longer depends on the select it can often be turned into a simpler
construct or even get hoisted out of the loop.
PR15340.
llvm-svn: 175995
|
|
|
|
| |
llvm-svn: 175994
|
|
|
|
| |
llvm-svn: 175993
|
|
|
|
|
|
| |
that they own
llvm-svn: 175992
|
|
|
|
| |
llvm-svn: 175991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fields.
This required more changes than I originally expected:
- ObjCIvarRegion implements "canPrintPretty" et al
- DereferenceChecker indicates the null pointer source is an ivar
- bugreporter::trackNullOrUndefValue() uses an alternate algorithm
to compute the location region to track by scouring the ExplodedGraph.
This allows us to get the actual MemRegion for variables, ivars,
fields, etc. We only hand construct a VarRegion for C++ references.
- ExplodedGraph no longer drops nodes for expressions that are marked
'lvalue'. This is to facilitate the logic in the previous bullet.
This may lead to a slight increase in size in the ExplodedGraph,
which I have not measured, but it is likely not to be a big deal.
I have validated each of the changed plist output.
Fixes <rdar://problem/12114812>
llvm-svn: 175988
|
|
|
|
|
|
|
| |
This provides a few sundry cleanups, and allows us to provide
a compile-time check for a case that was a runtime assertion.
llvm-svn: 175987
|
|
|
|
|
|
| |
This meant to be included in r175802.
llvm-svn: 175986
|
|
|
|
|
|
| |
Fix PR15239.
llvm-svn: 175985
|
|
|
|
|
|
| |
as early as possible; which means during instruction selection.
llvm-svn: 175984
|
|
|
|
| |
llvm-svn: 175983
|
|
|
|
|
|
| |
array type.
llvm-svn: 175982
|
|
|
|
|
|
| |
builds.
llvm-svn: 175981
|
|
|
|
|
|
|
| |
true when shouldOnlyCommute is false, so we can remove code that checks
otherwise.
llvm-svn: 175980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
itself recursively with a new instruction that has not been finalized, in order
to determine whether to keep the instruction. On 'make check' and test-suite the
only cases where the recursive invocation made any transformations were simple
instruction commutations, so I am restricting the recursive invocation to do
only this.
The other cases wouldn't work correctly when updating LiveIntervals, since the
new instructions don't have slot indices and LiveIntervals hasn't yet been
updated. If the other transformations were actually triggering in any test case
it would be possible to support it with a lot of effort, but since they don't
it's not worth it.
llvm-svn: 175979
|
|
|
|
|
|
|
|
| |
available the
full information about the macro (e.g if it was imported and where).
llvm-svn: 175978
|
|
|
|
| |
llvm-svn: 175977
|
|
|
|
|
|
|
|
|
|
|
|
| |
consumer
just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with
ASTConsumer::HandleTopLevelDecl.
ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls;
a consumer can treat an instantiated static data member however it wants of course.
llvm-svn: 175976
|
|
|
|
|
|
| |
proper. Fixed this already a few days ago for slti.
llvm-svn: 175975
|
|
|
|
|
|
|
| |
unless it was requested to with an optional parameter that defaults to false, so
we don't need to handle that case in TwoAddressInstructionPass.
llvm-svn: 175974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In conditional expressions, if the condition is split over multiple
lines, also break before both operands.
This prevents formattings like:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ? b : c;
Which are bad, because they suggestion incorrect operator precedence:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ? b : c);
This lead to the discovery that the expression parser incorrectly
handled conditional operators and that it could also handle semicolons
(which in turn reduced the amount of special casing for for-loops). As a
side-effect, we can now apply the bin-packing configuration to the
sections of for-loops.
llvm-svn: 175973
|
|
|
|
| |
llvm-svn: 175972
|
|
|
|
| |
llvm-svn: 175971
|