In the case where the constant comes from a cloned cast instruction, the
materialization code has to go before the cloned cast instruction.

This commit fixes the method that finds the materialization insertion point
by making it aware of this case.

This fixes <rdar://problem/15532441>

llvm-svn: 206913

[Constant Hoisting] Print the instructions in the correct order for debugging. No functional change.

llvm-svn: 206912

Patch by Maks Naumov!

llvm-svn: 206911

on CF type is not sufficient and bridge casting is
still required for proper ownership semantics.
// rdar://16650445

llvm-svn: 206910

We don't need the ASTContext for the diagnostics, only the language
options, which we can get from the compiler invocation. It worries me
how many categorically different states the ASTUnit class can be in
depending on how it is being constructed/used.

llvm-svn: 206909

Fix PR19487, PR19505 and PR19506 -- redundant vtordisp thunks when the final overrider is present in both a vbase and nvbase

Reviewed at http://reviews.llvm.org/D3449

llvm-svn: 206908

llvm-svn: 206907

diagnostic that includes location information.

Currently if one has this assembly:

	.quad (0x1234 + (4 * SOME_VALUE))

where SOME_VALUE is undefined ones gets the less than
useful error message with no location information:

% clang -c x.s
clang -cc1as: fatal error: error in backend: expected relocatable expression

With this fix one now gets a more useful error message
with location information:

% clang -c x.s 
x.s:5:8: error: expected relocatable expression
 .quad (0x1234 + (4 * SOME_VALUE))
       ^

To do this I plumbed the SMLoc through the MCObjectStreamer
EmitValue() and EmitValueImpl() interfaces so it could be used
when creating the MCFixup.

rdar://12391022

llvm-svn: 206906

llvm-svn: 206905

llvm-svn: 206904

llvm-svn: 206903

llvm-svn: 206902

Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 206901

Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 206900

llvm-svn: 206899

llvm-svn: 206898

llvm-svn: 206897

[asan] enable LeakSanitizer (LSan) by default in asan. This only affects Linux x86_64. LSan has been used in various projects for more than half a year and we now consider it quite stable to be on by default.

llvm-svn: 206896

Since these tests pass on (at least some) other platforms, change the
decorators to @expectedFailureDwarwin.  Tested on FreeBSD with Clang 3.4
and libc++.

rdar://9980907
rdar://15367233

llvm-svn: 206895

llvm-svn: 206894

  clang/include/clang/Format/Format.h:185:8: error: HTML tag 'tt' requires an end tag [-Werror,-Wdocumentation-html]
    /// <tt>@property (readonly)</tt> instead of <tt>@property(readonly)</tt>.
        ~^~~

llvm-svn: 206893

The other buildbots in the list include their build method.

llvm-svn: 206892

Differential Revision: http://reviews.llvm.org/D3272

llvm-svn: 206891

llvm-svn: 206890

llvm-svn: 206889

llvm-svn: 206888

llvm-svn: 206887

llvm-svn: 206886

Evidently tablegen doesn't infer this from the HasBMI2 predicate on the BZHI
instructions. This should fix the recent bot failures.

llvm-svn: 206885

Added encoding tests.

llvm-svn: 206884

llvm-svn: 206883

through to the output even if the input comment comes from an untrusted source

Attribute filtering is currently based on a blacklist, which right now includes
all event handler attributes (they contain JavaScipt code).  It should be
switched to a whitelist, but going over all of the HTML5 spec requires a
significant amount of time.

llvm-svn: 206882

Added a comment about keeping the Linux/Darwin test versions in sync.

llvm-svn: 206881

llvm-svn: 206880

suggested by Ben Kramer in review of r206738.

Thanks again Ben!

llvm-svn: 206879

No functional changes.

llvm-svn: 206878

llvm-svn: 206877

llvm-svn: 206876

This gives DAG patterns matching indexed patterns where either side is an
indexed vector.

llvm-svn: 206875

The point of these calls is to allow Thumb-1 code to make use of the VFP unit
to perform its operations. This is not desirable with -msoft-float, since most
of the reasons you'd want that apply equally to the runtime library.

rdar://problem/13766161

llvm-svn: 206874