llvm-svn: 182469

llvm-svn: 182468

Instead of selectively storing some changes and directly generating
replacements for others, we now notify the WhitespaceManager of the
whitespace before every token (and optionally with more changes inside
tokens).

Then, we run over all whitespace in the very end in original source
order, where we have all information available to correctly align
comments and escaped newlines.

The future direction is to pull more of the comment alignment
implementation that is now in the BreakableToken into the
WhitespaceManager.

This fixes a bug when aligning comments or escaped newlines in unwrapped
lines that are handled out of order:
  #define A \
    f({     \
      g();  \
    });
... now gets correctly layouted.

llvm-svn: 182467

Multiple connected changes:
- Ignore reads from nested interceptors.
- Check shadow on reads from common interceptors.
- getaddrinfo interceptor.

llvm-svn: 182466

llvm-svn: 182465

llvm-svn: 182464

llvm-svn: 182463

[asan] attempting to fix the debian bot (on ubuntu the test builds; on debian it complains that _SC_PAGESIZE is unknown)

llvm-svn: 182462

[asan] fix dlclose-test to work with non-4K pages. Properly disable interface_symbols_linux on non-x86

llvm-svn: 182461

The original version of the pass could underestimate the length of a backward
branch in cases like:

    alignment to N bytes or more
    ...
    relaxable branch A
    ...
 foo: (aligned to M<N bytes)
    ...
 bar: (aligned to N bytes)
    ...
    relaxable branch B to foo

We don't add any misalignment gap for "bar" because N bytes of alignment
had already been reached earlier in the function.  In this case, assuming
that A is relaxed can push "foo" closer to "bar", and make B appear to be
in range.  Similar problems can occur for forward branches.

I don't think it's possible to create blocks with mixed alignments as
things stand, not least because we haven't yet defined getPrefLoopAlignment()
for SystemZ (that would need benchmarking).  So I don't think we can test
this yet.

Thanks to Rafael Espíndola for spotting the bug.

llvm-svn: 182460

clang-format was a bit too aggressive when trying to keep labels and
values on the same line.

Before:
    llvm::outs()
         << "aaaaaaaaaaaaaaaaaaa: " << aaaaaaaaaaaaa(
                                           aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
  llvm::outs() << "aaaaaaaaaaaaaaaaaaa: "
               << aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 182458

This only affects styles that prevent bin packing. There, a break after
a template declaration also forced a line break after the function name.

Before:
template <class SomeType, class SomeOtherType>
SomeType
SomeFunction(SomeType Type, SomeOtherType OtherType) {}

After:
template <class SomeType, class SomeOtherType>
SomeType SomeFunction(SomeType Type, SomeOtherType OtherType) {}

This fixes llvm.org/PR16072.

llvm-svn: 182457

[asan] workaround for asan bug 189 (swapcontext followed by throw gets OOM kill). Also, disable swapcontext_test on non-x86. Fix lint

llvm-svn: 182456

Reduce the preference for breaking before a trailing 'const' according
to review comments on r182362.

llvm-svn: 182455

Allow LLVM to take advantage of shift instructions that set the ZF flag,
making instructions that test the destination superfluous.

llvm-svn: 182454

llvm-svn: 182453

R600ISelLowering.cpp: Avoid "using namespace Intrinsic;" to appease MSC. Specify namespaces explicitly here.

MSC is confused about "memcpy" between <cstring> and llvm::Intrinsic::memcpy, when llvm::Intrinsic were exposed.

llvm-svn: 182452

llvm-svn: 182451

Create an FPOW SDNode opcode def in the target independent .td file rather than in a specific backend.

llvm-svn: 182450

If clang-format is confronted with long and deeply nested lines (e.g.
complex static initializers or function calls), it can currently try too
hard to find the optimal solution and never finish. The reason is that
the memoization does not work effectively for deeply nested lines.

This patch removes an earlier workaround and instead opts for
accepting a non-optimal solution in rare cases. However, it only does
so only in cases where it would have to analyze an excessive number of
states (currently set to 10000 - the most complex line in Format.cpp
requires ~800 states) so this should not change the behavior in a
relevant way.

llvm-svn: 182449

the C API to provide their own way of allocating JIT memory (both code 
and data) and finalizing memory permissions (page protections, cache 
flush).

llvm-svn: 182448

Should fix the cmake bots that were already building R600.

llvm-svn: 182447

This should hopefully fix
http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32

llvm-svn: 182446

The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.

Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.

llvm-svn: 182445

llvm-svn: 182444

llvm-svn: 182443

The r600 backend has been in tree for some time now. Marking it as
non-experimental to avoid accidental breakage.

llvm-svn: 182442

Another fix to make sure that if we aren't able to extract an object file for any reason, we don't crash when trying to parse the debug map info.

llvm-svn: 182441

Add test case to make sure we don't regress on fat files full of skinny BSD archives.

llvm-svn: 182440

lldb crashes with universal file containing skinny BSD archives when doing DWARF with .o file debugging.

llvm-svn: 182437

operand of a unary address-of expression, not for *all* expressions!

llvm-svn: 182436

llvm-svn: 182435

llvm-svn: 182434

function templates can use it as a return type.

llvm-svn: 182433

*that* easy...

Try a bit harder to disambiguate. This is mostly straightforward, but for
=-style initializers, we actually need to know where an expression ends:

  [foo = bar baz]

is a message send, whereas

  [foo = bar + baz]

is a lambda-introducer. Handle this by parsing the expression eagerly, and
replacing it with an annotation token. By chance, we use the *exact same*
parsing rules in both cases (except that we need to assume we're inside a
message send for the parse, to turn off various forms of inapplicable
error recovery).

llvm-svn: 182432

a RegScavenger object on it's own.
 

llvm-svn: 182430

llvm-svn: 182429

Added a test case that verifies that LLDB can debug across a process exec'ing itself into a new program. This currently is only enabled for Darwin since we exec from 64 bit to 32 bit and vice versa for 'x86_64' targets.

This can easily be adapted for linux and other platforms, but I didn't want to break any buildbots by assuming it will work.

llvm-svn: 182428

llvm-svn: 182427

[analyzer;alternate edges] prune out extra edges to a subexpression where we dive-in and out of a subexpression.

Fixes <rdar://problem/13941891>.

llvm-svn: 182426