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

instead of messing with virtual files.

llvm-svn: 168062

as the include location of the main file of an imported module.

llvm-svn: 168061

llvm-svn: 168060

llvm-svn: 168059

llvm-svn: 168058

llvm-svn: 168057

FileCheck feature.  This will hopefully make tests less fragile.

llvm-svn: 168056

llvm-svn: 168055

positive.

In this particular case, R6 was being spilled by the register scavenger when it
was in fact dead.  The isUsed function reported R6 as used because the R6_R7
alias was reserved (due to the fact that we've reserved R7 as the FP).  The
solution is to only check if the original register (i.e., R6) isReserved and
not the aliases.  The aliases are only checked to make sure they're available.

The test case is derived from one of the nightly tester benchmarks and is rather
intractable and difficult to reproduce, so I haven't included it.
rdar://12592448

llvm-svn: 168054

Fixed an issue where lldb was setting breakpoints on too many methods when a partial function name with namespaces or class qualifiers was used. For example setting a breakpoint of "Foo::dealloc" was accidentally settings breakpoints on all objective C functions whose selector was "dealloc"...

llvm-svn: 168053

Remove aborts under __dynamic_cast which were under _LIBCXX_DYNAMIC_FALLBACK.  Change all type_info comparisons to use an inlined is_equal helper.  However no change in functionality for this latter change at this time.  This is just to encapsulate the comparison and make it a little easier to switch back and forth for testing/debugging.

llvm-svn: 168052

Similarly to several recent fixes throughout the code replace std::map use with the MapVector.
Add find() method to the MapVector.

llvm-svn: 168051

add interceptor for poll()
in addition process signals in every atomic op
in addition process signals in blocking libc functions

llvm-svn: 168050

llvm-svn: 168049

llvm-svn: 168048

llvm-svn: 168047

[ASan] Revert r168040 and r168043 and take a cleaner solution suggested by Kostya: return the known frame name for fake stack instead of looking it up.

llvm-svn: 168046