llvm-svn: 159606

This adds validation that the
* repro source is only rewrite-includes processed, not fully preprocessed.
* repro script contains macro definitions (-DFOO=BAR).

Based on suggestions/help by Matt Beaumont-Gay.

llvm-svn: 159605

Fixed an issue where GDB servers that don't support the thread suffix could get registers states incorrectly due to an incorrect assumption that the current register thread (set using the "Hg%x" packet) will always be cached between runs. Now we clear the cached register thred when the process is resumed.

llvm-svn: 159603

llvm-svn: 159601

llvm-svn: 159600

llvm-svn: 159599

a Clang target which hits the same bug directly.

llvm-svn: 159598

targets.

llvm-svn: 159597

llvm-svn: 159596

...and instead add an accessor. We're not using this today, but it's something
that should probably stay in the source for potential clients, and it doesn't
cost a lot. (ObjCPropertyAccess is only created on the stack, and right now
there's only ever one alive at a time.)

This reverts r159581 / commit 8e674e1da34a131faa7d43dc3fcbd6e49120edbe.

llvm-svn: 159595

Clang unit tests. It's not clear why we support this mode in builds
where LLVM is available (LLVM itself does not), but at least this makes
us support it correctly.

This also fixes a long-standing bug where we would pass the unit test
param flag to lit in the standalone build even though the standalone
build *never* has the unittests built and ready for testing.

llvm-svn: 159594

in the abstraction for lit test suites so that the various other layers
of abstraction pick up the same behavioral fix, and so that we still get
a complete list of dependencies for the 'check-all' target.

This should fix the follow-on issues of the same nature with various
other build targets, including Clang targets. Sorry for the churn, and
again thanks to Matt for testing and breaking this more thoroughly.

llvm-svn: 159593

Now that we're only using -frewrite-includes rather than full preprocessing
when producing repro source files, we should also include command line macro
definitions in the repro script.

I don't have a test case for this because I'm not sure if/how I can open the
crash report file when the name is only known by scraping the crash report
output. Suggestions welcome if anyone thinks it'd be helpful.

llvm-svn: 159592

In C, enum constants have the type of the enum's underlying integer type,
rather than the type of the enum. (This is not true in C++.) Thus, when a
block's return type is inferred from an enum constant, it is incompatible
with expressions that return the enum type.

In r158899, I told block returns to pretend that enum constants have enum
type, like in C++. Doug Gregor pointed out that this can break existing code.

Now, we don't check the types of return statements until the end of the block.
This lets us go back and add implicit casts in blocks with mixed enum
constants and enum-typed expressions.

<rdar://problem/11662489> (again)

llvm-svn: 159591

Part of rdar://6880388 and rdar://11766377

llvm-svn: 159590

No functionality changed here, except that the CMake installed by
default on Ubuntu Lucid should actually work with the makefile
generators now.

Thanks to Matt for the report and head-desking required to figure out
why it was failing.

llvm-svn: 159588

When we're looking for redeclarations which might provide a definition in CodeGen, make sure we examine all the redeclarations.  PR13252.

llvm-svn: 159586

llvm-svn: 159585

template instantiation. I wasn't able to reproduce this down to
anything small enough to put in our test suite, but it's "obviously"
okay to set the invalid bit earlier and precludes a
known-broken-but-not-marked-broken class from being used elsewhere.

llvm-svn: 159584

Patch by Matt Beaumont-Gay.

llvm-svn: 159583

standalone section of the Clang CMake files.

This will likely make the lit runs in Clang much more suitable to IDEs
such as Xcode and MSVC when operating in a standalone mode.

llvm-svn: 159582

This member became unused in r159559.

llvm-svn: 159581

'|&' bash syntax. We have lots of users with a bash on their system
which doesn't support this syntax, and as bash is still significantly
faster, we should support them.

The test suite has already been updated to cope with this.

llvm-svn: 159580

llvm-svn: 159579

we are encountering some scalability issues with memory usage.   The
appropriate long term fix is to make the analysis more scalable, but
this will at least prevent the analyzer swapping when
analyzing very large functions.

llvm-svn: 159578

in the call graph had been inlined but for whatever reason we did not inline some
of its callees.

Also, fix a related traversal bug where we meant to do a BFS of the callgraph but
instead were doing a DFS.

llvm-svn: 159577

the standalone mode. We've changed scoping and sequencing of variables
being defined and that cause this to start to be unset breaking some
cmake users. Thanks to Jordan Rose for the report.

The fix also makes the condition on the preceding line much more
sensible. =D

llvm-svn: 159576

due to strange scoping rules to the actual canonical variable name
within the LLVM CMake build.

No functionality changed.

llvm-svn: 159575

Contributer: Sasa Stankovic 
llvm-svn: 159574

the stack too often with 1024. Fixes <rdar://problem/11678534>.

llvm-svn: 159573

This is still a work in progress but I believe it is currently good enough
to fix PR13122 "Need unit test driver for codegen IR passes".  For example,
you can run llc with -stop-after=loop-reduce to have it dump out the IR after
running LSR.  Serializing machine-level IR is not yet supported but we have
some patches in progress for that.

The plan is to serialize the IR to a YAML file, containing separate sections
for the LLVM IR, machine-level IR, and whatever other info is needed.  Chad
suggested that we stash the stop-after pass in the YAML file and use that
instead of the start-after option to figure out where to restart the
compilation.  I think that's a great idea, but since it's not implemented yet
I put the -start-after option into this patch for testing purposes.

llvm-svn: 159570

llvm-svn: 159569

This makes it possible to just use a zero value to represent "no pass", so
the phony NoPassID global variable is no longer needed.

llvm-svn: 159568

This is a preliminary step toward having TargetPassConfig be able to
start and stop the compilation at specified passes for unit testing
and debugging.  No functionality change.

llvm-svn: 159567

llvm-svn: 159566

llvm-svn: 159565

llvm-svn: 159563

llvm-svn: 159562

llvm-svn: 159561

llvm-svn: 159560