Within the body of the loop the underlying map may be modified via

  Sema::AddOverloadCandidate
    -> Sema::CompareReferenceRelationship
    -> Sema::RequireCompleteType

to avoid the use of invalid iterators the sequence is copied first.

A reliable, though large, test case is available - it will be reduced and
committed shortly.

Patch by Robert Muth. Review by myself, Nico Weber, and Rafael Espindola.

llvm-svn: 166188

<rdar://problem/12068650>

More fixes to how we handle paths that are used to create a target.

This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".

llvm-svn: 166186

layer.  Use the new ParseMSInlineAsm() API and add an implementation of the
MCAsmParserSemaCallback interface.

llvm-svn: 166184

layer.  Add the ParseMSInlineAsm() function, which is the new interface to 
clang.  Also expose the new MCAsmParserSemaCallback interface, which is used
by the back-end to do name lookup in Sema.  Finally, remove the now defunct
APIs introduced in r165946.

llvm-svn: 166183

llvm-svn: 166181

llvm-svn: 166180

fixes the tests for builds without libxml2.

llvm-svn: 166179

test case on PowerPC caused by rounding errors when converting from a 64-bit
integer to a single-precision floating point. The reason for this are
double-rounding effects, since on PowerPC we have to convert to an
intermediate double-precision value first, which gets rounded to the
final single-precision result.

The patch fixes the problem by preparing the 64-bit integer so that the
first conversion step to double-precision will always be exact, and the
final rounding step will result in the correctly-rounded single-precision
result.  The generated code sequence is equivalent to what GCC would generate.

When -enable-unsafe-fp-math is in effect, that extra effort is omitted
and we accept possible rounding errors (just like GCC does as well).

llvm-svn: 166178

llvm-svn: 166177

operate purely on values. Sink the alloca loading and storing logic into
the rewrite routines that are specific to alloca-integer-rewrite
driving. This is just a refactoring here, but the subsequent step will
be to reuse the insertion and extraction logic when rewriting integer
loads and stores that have been split and decomposed into narrower loads
and stores.

No functionality changed other than different names for instructions.

llvm-svn: 166176

llvm-svn: 166175

llvm-svn: 166174

limitations of the pass manager stack in the pass manager builder.

llvm-svn: 166173

over the implicitly-formed-and-nesting CGSCC pass manager and function
pass managers, especially when using them on the opt commandline or
using extension points in the module builder. The '-barrier' opt flag
(or the pass itself) will create a no-op module pass in the pipeline,
resetting the pass manager stack, and allowing the creation of a new
pipeline of function passes or CGSCC passes to be created that is
independent from any previous pipelines.

For example, this can be used to test running two CGSCC passes in
independent CGSCC pass managers as opposed to in the same CGSCC pass
manager. It also allows us to introduce a further hack into the
PassManagerBuilder to separate the O0 pipeline extension passes from the
always-inliner's CGSCC pass manager, which they likely do not want to
participate in... At the very least none of the Sanitizer passes want
this behavior.

This fixes a bug with ASan at O0 currently, and I'll commit the ASan
test which covers this pass. I'm happy to add a test case that this pass
exists and works, but not sure how much time folks would like me to
spend adding test cases for the details of its behavior of partition
pass managers.... The whole thing is just vile, and mostly intended to
unblock ASan, so I'm hoping to rip this all out in a brave new pass
manager world.

llvm-svn: 166172

start seeing the bit so that we can find bugs and write tests for it.

llvm-svn: 166171

llvm-svn: 166170

llvm-svn: 166169

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