llvm-svn: 168111

llvm-svn: 168110

llvm-svn: 168109

dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!

llvm-svn: 168108

case to vector legalization so this actually works.

Patch by Pete Couperus.  Fixes PR12540.

llvm-svn: 168107

much work for this to make sense.  Just copy the current thread list and
operate on that.  Prevents some deadlocks.

llvm-svn: 168106

report)

llvm-svn: 168105

llvm-svn: 168104

llvm-svn: 168103

llvm-svn: 168102

llvm-svn: 168101

llvm-svn: 168099

and a non-fragile (that uses [[@LINE]]) parts.

llvm-svn: 168098

llvm-svn: 168095

llvm-svn: 168091

When libgmp header files are not installed in the default /usr/include location,
configure used to fail to find the gmp headers when testing for isl/ast.h.  This
patch adds the gmp include path to the compiler flags before testing for ISL.

llvm-svn: 168090

support and use it in place of HasMips32r2Or64.

llvm-svn: 168089

llvm-svn: 168088

"<invalid loc>" for summary.

llvm-svn: 168087

 
This patch lowers the llvm.floor, llvm.ceil, llvm.trunc, and
llvm.nearbyint to Altivec instruction when using 4 single-precision
float vectors.

llvm-svn: 168086

 - An LLVM unique_file() bug could cause us to infinite loop on the later test
   case.

llvm-svn: 168082

 - The code could infinite loop trying to create unique files, if the directory
   containing the unique file exists, but open() calls on non-existent files in
   the path return ENOENT. This is true on the /dev/fd filesystem, for example.

 - Will add a clang side test case for this.

llvm-svn: 168081

In code like this:

void foo() {
     bar();
     baz();
}

...the location for the call to 'bar()' was being used as a backup location
for the call to 'baz()'. This is fine unless the call to 'bar()' is deemed
uninteresting and that part of the path deleted.

(This looks like a logic error as well, but in practice the only way 'baz()'
could have an invalid location is if the entire body of 'foo()' is
synthesized, meaning the call to 'bar()' will be using the location of the
call to 'foo()' anyway. Nevertheless, the new version better matches the
intent of the code.)

Found by Matt Beaumont-Gay using ASan. Thanks, Matt!

llvm-svn: 168080

 - Realized I could use the /dev/fd filesystem to make a simple portable test.

llvm-svn: 168079

llvm-svn: 168078

llvm-svn: 168077

llvm-svn: 168076

Handle universal BSD archives correctly when parsing DWARF in .o files with debug map.

llvm-svn: 168075

to guarantee deterministic code generation.

llvm-svn: 168074

llvm-svn: 168073

Add myself as owner of VLIW Instruction Scheduling and Packetization.

llvm-svn: 168072

llvm-svn: 168071

This fixes a few cases where we'd emit path notes like this:

  +---+
 1|   v
  p = malloc(len);
  ^   |2
  +---+

In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.

llvm-svn: 168070

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168069

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168068

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168067

This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.

This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.

llvm-svn: 168066

Update the email address (old works too, but less reliable) while there

llvm-svn: 168065

llvm-svn: 168064

to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031 

llvm-svn: 168063