This only happens when the section header count is > 1024.

llvm-svn: 176747

it. Fortunately, versions of gcov that predate the extra checksum also ignore 
any extra data, so this isn't a problem. This matches the API change made in
r176745.

llvm-svn: 176746

it. Fortunately, versions of gcov that predate the extra checksum also ignore
any extra data, so this isn't a problem. There will be a matching commit in
compiler-rt.

llvm-svn: 176745

Previously, MallocChecker's pointer escape check and its post-call state
update for Objective-C method calls had a fair amount duplicated logic
and not-entirely-consistent checks. This commit restructures all this to
be more consistent and possibly allow us to be more aggressive in warning
about double-frees.

New policy (applies to system header methods only):
(1) If this is a method we know about, model it as taking/holding ownership
    of the passed-in buffer.
  (1a) ...unless there's a "freeWhenDone:" parameter with a zero (NO) value.
(2) If there's a "freeWhenDone:" parameter (but it's not a method we know
    about), treat the buffer as escaping if the value is non-zero (YES) and
    non-escaping if it's zero (NO).
(3) If the first selector piece ends with "NoCopy" (but it's not a method we
    know about and there's no "freeWhenDone:" parameter), treat the buffer
    as escaping.

The reason that (2) and (3) don't explicitly model the ownership transfer is
because we can't be sure that they will actually free the memory using free(),
and we wouldn't want to emit a spurious "mismatched allocator" warning
(coming in Anton's upcoming patch). In the future, we may have an idea of a
"generic deallocation", i.e. we assume that the deallocator is correct but
still continue tracking the region so that we can warn about double-frees.

Patch by Anton Yartsev, with modifications from me.

llvm-svn: 176744

so that it looks through certain syntactic forms and applies
even if normal inference would have succeeded.

There is potential for source incompatibility from this
change, but overall we feel that it produces a much
cleaner and more defensible result, and the block
compatibility rules should curb a lot of the potential
for annoyance.

rdar://13200889

llvm-svn: 176743

is non-anonymous or is defined in a typedef of itself.

llvm-svn: 176742

Add a missing "break" in processing the -h option to "breakpoint set".

llvm-svn: 176741

write a 32-byte value into a 32-byte ymm vector reg - that 
is allowed.
<rdar://problem/13350587> 

llvm-svn: 176740

improvements per Dmtiri's comments. // rdar://12379114

llvm-svn: 176739

noisy when dealing with anonymous structs.

<rdar://problem/13246914>

llvm-svn: 176738

r176010 introduced the notion of "interesting" lvalue expressions, whose
nodes are guaranteed never to be reclaimed by the ExplodedGraph. This was
used in bugreporter::trackNullOrUndefValue to find the region that contains
the null or undef value being tracked.

However, the /rvalue/ nodes (i.e. the loads from these lvalues that produce
a null or undef value) /are/ still being reclaimed, and if we couldn't
find the node for the rvalue, we just give up. This patch changes that so
that we look for the node for either the rvalue or the lvalue -- preferring
the former, since it lets us fall back to value-only tracking in cases
where we can't get a region, but allowing the latter as well.

<rdar://problem/13342842>

llvm-svn: 176737

Previously, ReturnVisitor waited to suppress a null return path until it
had found the inlined "return" statement. Now, it checks up front whether
the return value was NULL, and suppresses the warning right away if so.

We still have to wait until generating the path notes to invalidate the bug
report, or counter-suppression will never be triggered. (Counter-suppression
happens while generating path notes, but the generation won't happen for
reports already marked invalid.)

This isn't actually an issue today because we never reclaim nodes for
top-level statements (like return statements), but it could be an issue
some day in the future. (But, no expected behavioral change and no new
test case.)

llvm-svn: 176736

Reviewers: silvas, gribozavr
llvm-svn: 176735

PHIs are allowed to have multiple operand pairs per predecessor, and
this code works just fine when it happens.

llvm-svn: 176734

Summary:
Statistics are still available in Release+Asserts (any +Asserts builds),
and stats can also be turned on with LLVM_ENABLE_STATS.

Move some of the FastISel stats that were moved under DEBUG()
back out of DEBUG(), since stats are disabled across the board now.

Many tests depend on grepping "-stats" output.  Move those into
a orig_dir/Stats/. so that they can be marked as unsupported
when building without statistics.

Differential Revision: http://llvm-reviews.chandlerc.com/D486

llvm-svn: 176733

as suggested by Jordan.

llvm-svn: 176732

llvm-svn: 176731

The subdirectory has a lit.local.cfg that marks the tests unsupported
if llvm was built without Asserts.  There will be a patch in LLVM
that disables statistics gathering when built without Asserts so
that full Release builds can be faster.  Statistics can also
be enabled by building with -DLLVM_ENABLE_STATS.

llvm-svn: 176730

llvm-svn: 176729

This was causing correctness issues for ARC and the static analyzer when a
function template has "consumed" Objective-C object parameters (i.e.
parameters that will be released by the function before returning).

The fix is threefold:
(1) Actually copy over the attributes from old ParmVarDecls to new ones.
(2) Have Sema::BuildFunctionType only work for building FunctionProtoTypes,
    which it was doing anyway. This allows us to pass an ExtProtoInfo
    instead of a plain ExtInfo and several flags.
(3) Drop param attributes as part of StripImplicitInstantiation, which is
    used when an implicit instantiation is followed by an explicit one.

<rdar://problem/12685622>

llvm-svn: 176728

<rdar://problem/13094134> Don't try to wire up typedef names for invalid anonymous tag declarations encountered during template instantiation.

llvm-svn: 176727

No (intended) functionality change.

llvm-svn: 176726

Don't resolve .o file locations when setting the file spec for each .o file in DWARF with debug map. We should trust the path.

llvm-svn: 176725

llvm-svn: 176724

<rdar://problem/13140795> Transform the scope type of a pseudo-destructor expression within the object scope.

We were transforming the scope type of a pseudo-destructor expression
(e.g., the first T in x->T::~T()) as a freestanding type, which meant
that dependent template specialization types here would stay dependent
even when no template parameters were named. This would eventually
mean that a dependent expression would end up in what should be
fully-instantiated ASTs, causing IRgen to assert.

llvm-svn: 176723

llvm-svn: 176722

The getOperandPtr utility already bounds checks, but allows one-off-the-end.
This assert should catch the cases that could previously have been dereferencing
these one-off-the-end pointer. Happily, no cases of this came up with this
change.

llvm-svn: 176721

llvm-svn: 176720

parsing on the file name it gets.  That confuses
it if there are spaces in the file name.

<rdar://problem/13380392>

llvm-svn: 176719

(this code needs to be pushed up so that in the basic scenarios TestCase knows to dump all its measurements directly)

llvm-svn: 176718

the filename of the PCH file.

llvm-svn: 176717

Possible values are:
 1  : if a parameter was invalid
 -1 : if the callback returned CXVisit_Break,
 otherwise returns 0.

llvm-svn: 176716

This is a very basic implementation of a library that easily allows to drive LLDB.framework to write test cases for performance

This is separate from the LLDB testsuite in test/ in that:
a) this uses C++ instead of Python to avoid measures being affected by SWIG
b) this is in very early development and needs lots of tweaking before it can be considered functionally complete
c) this is not meant to test correctness but to help catch performance regressions

There is a sample application built against the library (in darwin/sketch) that uses the famous sample app Sketch as an inferior to measure certain basic parameters of LLDB's behavior.
The resulting output is a PLIST much like the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
	<dict>
		<key>fetch-frames</key>
		<real>0.13161715522222225</real>
	</dict>
	<dict>
		<key>file-line-bkpt</key>
		<real>0.029111678750000002</real>
	</dict>
	<dict>
		<key>fetch-modules</key>
		<real>0.00026376766666666668</real>
	</dict>
	<dict>
		<key>fetch-vars</key>
		<real>0.17820429311111111</real>
	</dict>
	<dict>
		<key>run-expr</key>
		<real>0.029676525769230768</real>
	</dict>
</array>
</plist>

Areas for improvement:
- code cleanups (I will be out of the office for a couple days this coming week, but please keep ideas coming!)
- more metrics and test cases
- better error checking

This toolkit also comprises a simple event-loop-driven controller for LLDB, similar yet much simpler to what the Driver does to implement the lldb command-line tool.

llvm-svn: 176715

counters for a variety of metrics associated
with expression parsing.  This should give some
idea of how much work the expression parser is
doing on Clang's behalf, and help with hopefully
reducing that load over time.

<rdar://problem/13210748> Audit type search/import for expressions

llvm-svn: 176714

There are no python modules in clang-tools-extra so a link to this
auto-generated page, which currently isn't generated anyway, is not necessary.

llvm-svn: 176713

Turned on doxygen warnings and fixed the resulting problems.

llvm-svn: 176712

Parsing floating point numbers with very long precision was broken, and this patch fixes it.  This fixes http://llvm.org/bugs/show_bug.cgi?id=15445.

llvm-svn: 176711

1. We now ignore all non-default string literals, including raw
literals.
2. We do not break inside escape sequences any more.

FIXME: We still break in trigraphs.
llvm-svn: 176710

Since no_xform is not a bug to be fixed, made the test pass using the 'not'
utility and removed XFAIL.

llvm-svn: 176709

Clearly, this function is never actually called with the last
instruction in the function.

llvm-svn: 176708