| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The analyzer cannot reason about the internal invariances of the data structure (radar://15194597).
llvm-svn: 194004
|
| |
|
|
| |
llvm-svn: 194003
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Similar C code isn't caught as it seems to hit a different code path.
Also, as the check is only done for record pointers, cases involving
an overloaded operator-> are not handled either. Note that the reason
this check is done in the parser instead of Sema is not related to
having enough knowledge about the current state as it is about being
able to fix up the parser's state to be able to recover and traverse the
correct code paths.
llvm-svn: 194002
|
| |
|
|
| |
llvm-svn: 194001
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
We just have to be careful to produce the same aliases in every TU because
of comdats.
llvm-svn: 194000
|
| |
|
|
| |
llvm-svn: 193997
|
| |
|
|
|
|
|
|
| |
In order to create an ObjectFile implementation that uses bitcode files, we
need to propagate the bitcode errors to the ObjectFile interface, so we need
to convert it to use the same error handling as ObjectFile: error_code.
llvm-svn: 193996
|
| |
|
|
| |
llvm-svn: 193995
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
A while ago EmitForStmt was changed to explicitly evaluate the
condition expression and create a branch instead of using
EmitBranchOnBool, so that the condition expression could be used for
some cleanup logic. The cleanup stuff has since been reorganized, and
this is no longer necessary.
In EmitCXXForRange, the evaluated condition was never used for
anything else. The logic was presumably modeled on EmitForStmt.
llvm-svn: 193994
|
| |
|
|
|
|
|
|
| |
An initialization somehow found its way in between a comment and the
block of code the comment is about. Moving the initialization makes
this less confusing.
llvm-svn: 193993
|
| |
|
|
| |
llvm-svn: 193992
|
| |
|
|
|
|
| |
ClangAttrTypeArg is required here.
llvm-svn: 193991
|
| |
|
|
| |
llvm-svn: 193990
|
| |
|
|
|
|
| |
coded into the parser. Instead, they are automatically listed through tablegen.
llvm-svn: 193989
|
| |
|
|
| |
llvm-svn: 193988
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
at some point in the past. We may have nothing more than a pc value
for this type of stack frame -- hopefully we'll have a pc and a
stop_id so we can track module loads and unloads over time and
symbolicate the pc at the correct point in time.
Also add a flag to indicate if the CFA for the frame is available
(a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an
overall setting to indicate whether this is a history stack frame
or not. A history stack frame may not have a CFA, it may not have
a register context, it may not have variables, it may not have a
frame pointer or a stack pointer.
<rdar://problem/15314068>
llvm-svn: 193987
|
| |
|
|
|
|
| |
PR17796.
llvm-svn: 193986
|
| |
|
|
| |
llvm-svn: 193985
|
| |
|
|
|
|
| |
This is just bdver2 + FSGSBase.
llvm-svn: 193984
|
| |
|
|
|
|
|
|
|
|
| |
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
|
| |
|
|
| |
llvm-svn: 193982
|
| |
|
|
|
|
|
|
| |
This patch should fix the test when it runs on Windows, by allowing drive
letter separator (colon) in the path. Now all LLD ELF tests passed on MSVC
2012 32-bit. Hooray!
llvm-svn: 193978
|
| |
|
|
|
|
|
| |
the same virtual base class multiple times (and the move assignment is used,
and the move assignment for the virtual base is not trivial).
llvm-svn: 193977
|
| |
|
|
|
|
|
| |
MSVC 2012 raises an error in the lambda passed to vector::find_if, while it
seems valid code. Rewrote without high-order functions.
llvm-svn: 193975
|
| |
|
|
| |
llvm-svn: 193974
|
| |
|
|
| |
llvm-svn: 193973
|
| |
|
|
| |
llvm-svn: 193972
|
| |
|
|
|
|
|
|
|
| |
Enable pretty
stack traces by default if you use PrettyStackTraceProgram, so that existing LLVM-based
tools will continue to get it without any changes.
llvm-svn: 193971
|
| |
|
|
| |
llvm-svn: 193970
|
| |
|
|
|
|
|
|
|
|
|
| |
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
llvm-svn: 193969
|
| |
|
|
| |
llvm-svn: 193968
|
| |
|
|
| |
llvm-svn: 193967
|
| |
|
|
| |
llvm-svn: 193966
|
| |
|
|
| |
llvm-svn: 193965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the sole distinction between two declarations is that one has a
__restrict qualifier then we should not consider it to be an overload.
Instead, we will consider it as an incompatible redeclaration which is
similar to how MSVC, ICC and GCC would handle it.
This fixes PR17786.
N.B. We must not mangle in __restrict into method qualifiers becase we
don't allow overloading between such declarations anymore. To do
otherwise would be a violation of the Itanium ABI.
llvm-svn: 193964
|
| |
|
|
|
|
| |
the catch
llvm-svn: 193963
|
| |
|
|
| |
llvm-svn: 193962
|
| |
|
|
|
|
| |
one succeeds.
llvm-svn: 193960
|
| |
|
|
|
|
| |
added EVEX_KZ to tablegen
llvm-svn: 193959
|
| |
|
|
| |
llvm-svn: 193958
|
| |
|
|
| |
llvm-svn: 193957
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of doing a RPO traversal of the whole function remember the blocks
containing gathers (typically <= 2) and scan them in dominator-first order.
The actual CSE is still quadratic, but I'm not confident that adding a
scoped hash table here is worth it as we're only looking at the generated
instructions and not arbitrary code.
llvm-svn: 193956
|
| |
|
|
|
|
|
|
| |
This reverts commit r193356, it caused PR17781.
A reduced test case covering this regression has been added to the test suite.
llvm-svn: 193955
|
| |
|
|
| |
llvm-svn: 193954
|
| |
|
|
| |
llvm-svn: 193953
|
| |
|
|
|
|
| |
OCaml's type unit is not compatible with C's type void.
llvm-svn: 193952
|
| |
|
|
| |
llvm-svn: 193951
|
| |
|
|
| |
llvm-svn: 193950
|
| |
|
|
|
|
|
| |
Llvm_target tests did not check for return values. This actually
caused them to miss a bug.
llvm-svn: 193949
|
| |
|
|
| |
llvm-svn: 193948
|