llvm-svn: 113867

expressions.  This involved three main changes:

 - In ClangUserExpression::ClangUserExpression(),
   we now insert the following lines into the
   expression:
     #define this ___clang_this
     #define self ___clang_self

 - In ClangExpressionDeclMap::GetDecls(), we
   special-case ___clang_(this|self) and instead
   look up "this" or "self"

 - In ClangASTSource, we introduce the capability
   to generate Decls with a different, overridden,
   name from the one that was requested, e.g.
   this for ___clang_this.

llvm-svn: 113866

llvm-svn: 113865

that we're sure to keep it updated when new expression kinds
emerge. Also fixes a few little bugs in the classification of
expressions.

llvm-svn: 113864

llvm-svn: 113863

Rename 'MaxLoop' to 'MaxVisit' in AnalysisManager to more correctly reflect that we aborted analysis may not necessarily be due to a loop.

llvm-svn: 113862

placement 'operator delete', even if there are no placement args (i.e.
overload resolution selected an operator new with default arguments).

llvm-svn: 113861

llvm-svn: 113860

llvm-svn: 113859

isn't a good level of abstraction for memdep. Instead, generalize
AliasAnalysis::alias and related interfaces with a new Location
class for describing a memory location. For now, this is the same
Pointer and Size as before, plus an additional field for a TBAA tag.

Also, introduce a fixed MD_tbaa metadata tag kind.

llvm-svn: 113858

llvm-svn: 113857

llvm-svn: 113856

llvm-svn: 113855

an argument, so that we can distinguish instructions with the same register
classes but different numbers of registers (e.g., vld3 and vld4).  Fix some
of the non-pseudo NEON ld/st instruction itineraries to reflect the number
of registers loaded or stored, not just the opcode name.

llvm-svn: 113854

on by default and has received significant testing.

llvm-svn: 113852

llvm-svn: 113850

llvm-svn: 113849

llvm-svn: 113848

llvm-svn: 113847

llvm-svn: 113846

Now isFunctionLocal is reset, if required,  when operands are modified.

llvm-svn: 113845

llvm-svn: 113844

Use frame index, if available for byval argument while lowering dbg_declare. Otherwise let getRegForValue() find register for this argument.

llvm-svn: 113843

llvm-svn: 113842

llvm-svn: 113840

by morphing the 'and' to its recording form 'andS'.

This is basically a test commit into this area, to
see whether the bots like me. Several generalizations
can be applied and various avenues of code simplification
are open. I'll introduce those as I go.

I am aware of stylistic input from Bill Wendling, about
where put the analysis complexity, but I am positive
that we can move things around easily and will find a
satisfactory solution.

llvm-svn: 113839

documents the status-quo with its opportunities

llvm-svn: 113838

llvm-svn: 113837

(but not if destructors associated with the full-expression throw).

llvm-svn: 113836

llvm-svn: 113835

This may produce warnings on MSVS, but it's better than failures.

llvm-svn: 113834

llvm-svn: 113833

llvm-svn: 113832

to any inferior process because the code was checking if no run args were
set and then adding and empty string. This was happening for environment
vars as well.

llvm-svn: 113831

to return the correct result.

Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct
result when there are no location lists.

Modified the "frame variable" command such that:
- if no arguments are given (dump all frame variables), then we only show
  variables that are currently in scope
- if some arguments are given, we show an error if the variable is out of 
  scope

llvm-svn: 113830

debug map showed that the location lists in the .o files needed some 
refactoring in order to work. The case that was failing was where a function
that was in the "__TEXT.__textcoal_nt" in the .o file, and in the 
"__TEXT.__text" section in the main executable. This made symbol lookup fail
due to the way we were finding a real address in the debug map which was
by finding the section that the function was in in the .o file and trying to
find this in the main executable. Now the section list supports finding a
linked address in a section or any child sections. After fixing this, we ran
into issue that were due to DWARF and how it represents locations lists. 
DWARF makes a list of address ranges and expressions that go along with those
address ranges. The location addresses are expressed in terms of a compile
unit address + offset. This works fine as long as nothing moves around. When
stuff moves around and offsets change between the remapped compile unit base
address and the new function address, then we can run into trouble. To deal
with this, we now store supply a location list slide amount to any location
list expressions that will allow us to make the location list addresses into
zero based offsets from the object that owns the location list (always a
function in our case). 

With these fixes we can now re-link random address ranges inside the debugger
for use with our DWARF + debug map, incremental linking, and more.

Another issue that arose when doing the DWARF in the .o files was that GCC
4.2 emits a ".debug_aranges" that only mentions functions that are externally
visible. This makes .debug_aranges useless to us and we now generate a real
address range lookup table in the DWARF parser at the same time as we index
the name tables (that are needed because .debug_pubnames is just as useless).
llvm-gcc doesn't generate a .debug_aranges section, though this could be 
fixed, we aren't going to rely upon it.

Renamed a bunch of "UINT_MAX" to "UINT32_MAX".

llvm-svn: 113829

non-function-local value, it may result in the metadata no longer needing to be
function-local. Check for this condition, and clear the isFunctionLocal flag, if
it's still in the uniquing map, since any node in the uniquing map needs to have
an accurate function-local flag.

Also, add an assert to help catch problematic cases.

llvm-svn: 113828

llvm-svn: 113827

llvm-svn: 113826

was used to set the selected thread if none was selected.  Use a more robust
API to accomplish the task.

Also fixed an error found, while investigating, in CommandObjectThreadSelect::
Execute() where the return status was not properly set if successful.

As a result, both the stl step-in test cases with expectedFailure decorators now
passed.

llvm-svn: 113825