llvm-svn: 193991

llvm-svn: 193990

Attributes which accept a type as their sole argument are no longer hard 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

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

llvm-svn: 193963

llvm-svn: 193962

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

llvm-svn: 193947