llvm-svn: 171924

This is causing some problems. The root cause is unknown at this time.

llvm-svn: 171923

  - this expression is explicitly marked no-signed-zero, or
  - no-signed-zero of this expression can be derived from some context.

llvm-svn: 171922

in lambdas.

llvm-svn: 171921

llvm-svn: 171920

global variable.

llvm-svn: 171919

llvm-svn: 171918

llvm-svn: 171917

llvm-svn: 171916

llvm-svn: 171915

Add an SBProcess API to get the current StopID, either considering or ignoring stops caused by expression
evaluation.

<rdar://problem/12968562>

llvm-svn: 171914

llvm-svn: 171913

struct variables with flexiable array members in
blocks (and lambdas). Issue error instead of
crashing in IRGen. // rdar://12655829

llvm-svn: 171912

There is no way to test this at the moment because the options are not
processed until the link starts, and we can't pass an empty file.

llvm-svn: 171910

llvm-svn: 171909

llvm-svn: 171908

llvm-svn: 171906

llvm-svn: 171905

Checking in the support for doing index ids reservation when given a thread id.

llvm-svn: 171904

method because getContents().size() already covers it. So computeFragmentSize
can use the generic MCEncodedFragment interface when querying both Data and
Relaxable fragments for contents sizes.

No change in functionality

llvm-svn: 171903

llvm-svn: 171902

Python OS plug-ins now fetch thread registers lazily.

Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".

llvm-svn: 171901

llvm-svn: 171900

llvm-svn: 171899

llvm-svn: 171898

llvm-svn: 171897

Stop using BumpPtrAllocator for HNodes because
they have fields (vector, map) which require HNode 
destructors to be run.

llvm-svn: 171896

llvm-svn: 171895

llvm-svn: 171894

-Wint-to-pointer-cast, added to match GCC's warning by the same name, doesn't
need to be in any other groups (as it isn't in any groups in GCC either).

Found in post-commit review by Ted Kremenek.

llvm-svn: 171893

llvm-svn: 171892

With the new setting, we are not going to inline any functions that are
more than 50 basic blocks. (The analyzer is 20% faster on several
especially bad benchmarks with the new default.)

llvm-svn: 171891

Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa, *
                                                 aaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaa, *aaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 171890

Thanks to Dmitri Gribenko for the suggestion.

llvm-svn: 171889

In the source

  static void f();
  static void f();
  template<typename T>
  static void g() {
    f();
  }
  static void f() {
  }
  void h() {
    g<int>();
  }

the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.

With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.

llvm-svn: 171888

llvm-svn: 171887

This avoids FileCheck failing over different comment characters in
assembly (notably powerpc64 on Linux vs Darwin) and should fix David's
build-bot.

llvm-svn: 171886

llvm-svn: 171885

This makes us more optimistic when matching reports in a changing code
base. Addresses Jordan's feedback for r171825.

llvm-svn: 171884

llvm-svn: 171883