llvm-svn: 181434

As suggested by Dmitri Gribenko.

llvm-svn: 181433

llvm-svn: 181431

If the LHS of a binary expression is broken, clang-format should also
break after the operator as otherwise:
- The RHS can be easy to miss
- It can look as if clang-format doesn't understand operator precedence

Before:
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
                                 bbbbbbbbbbbbbbbbbb && ccccccccc == ddddddddddd;
After:
bool aaaaaaaaaaaaaaaaaaaaa =
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa != bbbbbbbbbbbbbbbbbb &&
    ccccccccc == ddddddddddd;

As an additional note, clang-format would also be ok with the following
formatting, it just has a higher penalty (IMO correctly so).
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
                                 bbbbbbbbbbbbbbbbbb &&
                             ccccccccc == ddddddddddd;

llvm-svn: 181430

llvm-svn: 181429

llvm-svn: 181428

Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen.  I considered adding a Decl AST node
for this, but it seemed too heavyweight.

Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking.  This change follows that pattern.

LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong.  ELF support is not
implemented, but possible.

This is related to auto-linking, which is http://llvm.org/PR13016.

CC: cfe-commits

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

llvm-svn: 181426

Adapted from the llvm.SI.sample test.

Reviewed-by: Christian König <christian.koenig@amd.com>
llvm-svn: 181425

llvm-svn: 181424

The floating-point record forms on PPC don't set the condition register bits
based on a comparison with zero (like the integer record forms do), but rather
based on the exception status bits.

llvm-svn: 181423

This is the first in a sequence of changes designed to eliminate the
libc dependency in sanitizer_common.  The main motivation for these
changes is to be able to provide an alternative for the current
interceptor-based technique for instrumenting functions in libc.
In this new technique, we compile libc with instrumentation.  This has
the potential advantages of being more accurate than interception and
reducing the amount of custom code required for each libc function.
As a side effect of this, we cannot depend on libc in the sanitizer
runtime due to mutual dependency issues.

This change disables the GCC stack protector, which introduces a libc
dependency and is enabled by default in Ubuntu.

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

llvm-svn: 181422

Before:
aaaaaaaa::
    aaaaaaaa::
    aaaaaaaa();
After:
aaaaaaaa::
    aaaaaaaa::
        aaaaaaaa();

The reason for the change is that:
a) we are not sure which is better
b) it is a really rare edge case
c) it simplifies the code
d) it currently causes problems with memoization

llvm-svn: 181421

The reference encoding is correct, but written in the wrong byte order (these are Thumb tests, while the reference is in ARM byte order).

llvm-svn: 181420

llvm-svn: 181418

llvm-svn: 181402

by switching to a ValueMap. Patch by Andrea DiBiagio!

llvm-svn: 181397

llvm-svn: 181396

Fold (xor (and x, y), y) -> (and (not x), y)

This removes an opportunity for a constant to appear twice.

llvm-svn: 181395

Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).

llvm-svn: 181393

This provides basic functionality for imported declarations. For
subprograms and types some amount of lazy construction is supported (so
the definition of a function can proceed the using declaration), but it
still doesn't handle declared-but-not-defined functions (since we don't
generally emit function declarations).

Variable support is really rudimentary at the moment - simply looking up
the existing definition with no support for out of order (declaration,
imported_module, then definition).

llvm-svn: 181392

llvm-svn: 181391

More of rdar://13200889.

llvm-svn: 181390

llvm-svn: 181389

llvm-svn: 181388

in the underlying llvm::JITMemoryManager API.

llvm-svn: 181387

range, it should set the error in the Error passed into the function.

llvm-svn: 181386

llvm-svn: 181385

llvm-svn: 181384

instead of relying upon an extra call to finish initializing.

llvm-svn: 181383

value.  This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh!  I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.

Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming.  That allows 
us to handle resuming in a more controlled fashion.

Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--

M    test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M    include/lldb/Target/ThreadList.h
M    include/lldb/Target/ThreadPlanStepOut.h
M    include/lldb/Target/Thread.h
M    include/lldb/Target/ThreadPlanBase.h
M    include/lldb/Target/ThreadPlanStepThrough.h
M    include/lldb/Target/ThreadPlanStepInstruction.h
M    include/lldb/Target/ThreadPlanStepInRange.h
M    include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M    include/lldb/Target/ThreadPlanStepUntil.h
M    include/lldb/Target/StopInfo.h
M    include/lldb/Target/Process.h
M    include/lldb/Target/ThreadPlanRunToAddress.h
M    include/lldb/Target/ThreadPlan.h
M    include/lldb/Target/ThreadPlanCallFunction.h
M    include/lldb/Target/ThreadPlanStepOverRange.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M    source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M    source/Target/StopInfo.cpp
M    source/Target/Process.cpp
M    source/Target/ThreadPlanRunToAddress.cpp
M    source/Target/ThreadPlan.cpp
M    source/Target/ThreadPlanCallFunction.cpp
M    source/Target/ThreadPlanStepOverRange.cpp
M    source/Target/ThreadList.cpp
M    source/Target/ThreadPlanStepOut.cpp
M    source/Target/Thread.cpp
M    source/Target/ThreadPlanBase.cpp
M    source/Target/ThreadPlanStepThrough.cpp
M    source/Target/ThreadPlanStepInstruction.cpp
M    source/Target/ThreadPlanStepInRange.cpp
M    source/Target/ThreadPlanStepOverBreakpoint.cpp
M    source/Target/ThreadPlanStepUntil.cpp
M    lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme

llvm-svn: 181381

llvm-svn: 181378

Constrain __invoke functions more accurately.  This fixes http://llvm.org/bugs/show_bug.cgi?id=15861 .

llvm-svn: 181377

C++1y constant expression evaluation: compound assignment support for floating-point and pointer types.

llvm-svn: 181376

a new section is added to the executable after the dSYM has been created, e.g.
the CTF segment added to mach_kernel after all other linking and processing has
been finished.
<rdar://problem/13258780> 

llvm-svn: 181375

llvm-svn: 181374

llvm-svn: 181373

llvm-svn: 181372

llvm-svn: 181371

return all the overloads instead of just picking the first possible declaration.
This removes an invalid note (and on occasion other invalid diagnostics) and
also makes clang's parsing recovery behave as if the text from its fixit were
applied.

llvm-svn: 181370

The two nested loops were confusing and also conservative in identifying
reduction variables. This patch replaces them by a worklist based approach.

llvm-svn: 181369