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

miscompiled by the system gcc-4.2.1

The test remains enabled for the second-stage test.

llvm-svn: 113824

llvm.stacksave/llvm.stackrestore wasn't emitted for VLAs in inner scopes.
Fixes r8403108.

llvm-svn: 113822

I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.

llvm-svn: 113821

deleted.  Fix this by doing the copyValue's before we delete stuff!

The testcase only repros the problem on my system with valgrind.

llvm-svn: 113820

This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819

register allocation.  Remove the NEONPreAllocPass, which is no longer needed.
Yeah!!

llvm-svn: 113818

This reverts commit r113631

Conflicts:

	CMakeLists.txt
	lib/CodeGen/CMakeLists.txt

llvm-svn: 113817

edited without actually using LiveIntervalMap functionality.

llvm-svn: 113816

llvm-svn: 113815

This test created a statements.ll file until about a month ago. Some buildbots
still have this file in their source dir. This is the easiest way to remove the
file on all bots. Then I'll revert.

llvm-svn: 113814

char32_t, respectively, but which can also be used in C++98/03
mode. Fixes <rdar://problem/8418510>.

llvm-svn: 113813

pseudo-instruction approach.  Change ARMExpandPseudoInsts to use a table
to record all the NEON load/store information.

llvm-svn: 113812

to an "overloaded" set of declarations. This cursor kind works for
unresolved references to functions/templates (e.g., a call within a
template), using declarations, and Objective-C class and protocol
forward declarations.

llvm-svn: 113805

llvm-svn: 113804

llvm-svn: 113803

llvm-svn: 113801