The TargetTransform changes are breaking LTO bootstraps of clang.  I am
working with Nadav to figure out the problem, but I am reverting it for now
to get our buildbots working.

This reverts svn commits: 165665 165669 165670 165786 165787 165997
and I have also reverted clang svn 165741

llvm-svn: 166168

llvm-svn: 166167

block, which stores information about how the AST file to generated,
from the AST block, which stores the actual serialized AST. The
information in the control block should be enough to determine whether
the AST file is up-to-date and compatible with the current translation
unit, and reading it should not cause any side effects that aren't
easy to undo. That way, we can back out from an attempt to read an
incompatible or out-of-date AST file.

Note that there is still more factoring to do. In particular,
information about the source files used to generate the AST file
(along with their time stamps, sizes, etc.) still resides in the
source manager block. 

llvm-svn: 166166

     for (i=0; i<n; i++){
        a[i] = b[i+1] + c[i+3];
     }

llvm-svn: 166165

Nadav's llvm change r165665 caused problems with an LTO bootstrap of clang,
so I'm reverting it for now, along with follow-on patches like this one.

llvm-svn: 166164

llvm-svn: 166163

llvm-svn: 166162

llvm-svn: 166161

llvm-svn: 166160

llvm-svn: 166159

llvm-svn: 166158

llvm-svn: 166157

expressions, not *any* typeid on a polymorphic class type.

llvm-svn: 166156

- Folding (trunc (concat ... X )) to (concat ... (trunc X) ...) is valid
  when '...' are all 'undef's.
- r166125 relies on this transformation.

llvm-svn: 166155

Fix -Woverloaded-virtual when the using statement refers to a base declaration of a virtual function.

GCC and Clang both do not warn on:

  struct a { virtual void func(); };
  struct b: a { virtual void func(); void func(int); };
  struct c: b { void func(int); using b::func; };

but if the "using" was using a::func GCC would still remain silent where Clang
would warn. This change makes Clang consistent with GCC's existing behavior.

llvm-svn: 166154

llvm-svn: 166153

llvm-svn: 166152

other platforms.

llvm-svn: 166151

off. // rdar://12501960

llvm-svn: 166150

llvm-svn: 166141

llvm-svn: 166139

llvm-svn: 166138

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) = 

There is also the program argument that are separate from the first argument that have existed for a while:

target.run-args (arguments) =

When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args

Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.

llvm-svn: 166137

- In general, it's unsafe for this transformation.

llvm-svn: 166135

llvm-svn: 166134

llvm-svn: 166133

using a reference-counted pointer.  This avoids
memory-management problems when the TargetOptions
are deleted.

llvm-svn: 166132

the expression parser (also wchar_t) and added a
test case.

llvm-svn: 166131

XML comment for declarations which pretty-prints
declaration. I had to XFAIL one test annotate-comments.cpp.
This test is currently unmaintainable as written.
Dmitri G., can you see what we can do about this test.
We should change this test such that adding a new tag does not wreck
havoc to the test.

llvm-svn: 166130

clang_version, fix the compare routine.

llvm-svn: 166129

llvm-svn: 166128

Added register write examples and also how to modify the pc. For this we show and example of GDB using the "jump" command, and LLDB using "register write" with an expression.

llvm-svn: 166127

- If the extracted vector has the same type of all vectored being concatenated
  together, it should be simplified directly into v_i, where i is the index of
  the element being extracted.

llvm-svn: 166125

This is a more compact, less redundant representation, and it avoids
scanning long lists of aliases for ARM D-registers, for example.

llvm-svn: 166124

llvm-svn: 166123

any scheduling heuristics nor does it build up any scheduling data structure
that other heuristics use. It essentially linearize by doing a DFA walk but
it does handle glues correctly.

IMPORTANT: it probably can't handle all the physical register dependencies so
it's not suitable for x86. It also doesn't deal with dbg_value nodes right now
so it's definitely is still WIP.

rdar://12474515

llvm-svn: 166122

This actually looks through several kinds of expression, such as
OpaqueValueExpr and ExprWithCleanups. The idea is that binding and lookup
should be consistent, and so if the environment needs to be modified later,
the code doing the modification will not have to manually look through these
"transparent" expressions to find the real binding to change.

This is necessary for proper updating of struct rvalues as described in
the previous commit.

llvm-svn: 166121

In C++, rvalues that need to have their address taken (for example, to be
passed to a function by const reference) will be wrapped in a
MaterializeTemporaryExpr, which lets CodeGen know to create a temporary
region to store this value. However, MaterializeTemporaryExprs are /not/
created when a method is called on an rvalue struct, even though the 'this'
pointer needs a valid value. CodeGen works around this by creating a
temporary region anyway; now, so does the analyzer.

The analyzer also does this when accessing a field of a struct rvalue.
This is a little unfortunate, since the rest of the struct will soon be
thrown away, but it does make things consistent with the rest of the
analyzer.

This allows us to bring back the assumption that all known 'this' values
are Locs. This is a revised version of r164828-9, reverted in r164876-7.

<rdar://problem/12137950>

llvm-svn: 166120

<rdar://problem/12503640> Fixing an issue where the dynamic type of an Objective-C pointer changed but we still reported the one-true-definition for the previous type. This was causing issues where a variable could be reported as being of an entirely different type after an assignment

llvm-svn: 166119

Addressing feedback on r166039 given by Matt Beaumont-Gay.

llvm-svn: 166118