different number of elements.

Bitcasts were passing with vectors of pointers with different number of
elements since the number of elements was checking
SrcTy->getVectorNumElements() == SrcTy->getVectorNumElements() which
isn't helpful. The addrspacecast was also wrong, but that case at least
is caught by the verifier. Refactor bitcast and addrspacecast handling
in castIsValid to be more readable and fix this problem.

llvm-svn: 199821

not using backing ivar warning, ignore when
property is not being synthesized (user declared its
implementation @dynamic). // rdar://1583425

llvm-svn: 199820

currently, for thumbv8, two predefined macros are missing:
 define __THUMB_INTERWORK__ 1
 define __THUMB_INTERWORK__ 1

This patch adds them for thumbv8.

llvm-svn: 199819

This patch restores the ARM mode if the user's inline assembly
does not.  In the object streamer, it ensures that instructions
following the inline assembly are encoded correctly and that
correct mapping symbols are emitted.  For the asm streamer, it
emits a .arm or .thumb directive.

This patch does not ensure that the inline assembly contains
the ADR instruction to switch modes at runtime.

The problem we need to solve is code like this:

  int foo(int a, int b) {
    int r = a + b;
    asm volatile(
        ".align 2     \n"
        ".arm         \n"
        "add r0,r0,r0 \n"
    : : "r"(r));
    return r+1;
  }

If we compile this function in thumb mode then the inline assembly
will switch to arm mode. We need to make sure that we switch back to
thumb mode after emitting the inline assembly or we will incorrectly
encode the instructions that follow (i.e. the assembly instructions
for return r+1).

Based on patch by David Peixotto

Change-Id: Ib57f6d2d78a22afad5de8693fba6230ff56ba48b
llvm-svn: 199818

Before:
  std::unique_ptr<int[]> foo() {}

After:
  std::unique_ptr<int []> foo() {}

Also, the formatting could go severely wrong after such a function
before.

llvm-svn: 199817

We still read/mmap them twice, but the fix for that is a bit more complex.

llvm-svn: 199815

Found by -Wdocumentation.

llvm-svn: 199814

identify_magic is not free, so we should avoid calling it twice. The argument
also makes it cheap for createBinary to just forward to createObjectFile.

llvm-svn: 199813

llvm-svn: 199812

llvm-svn: 199811

llvm-svn: 199810

llvm-svn: 199809

llvm-svn: 199808

llvm-svn: 199807

llvm-svn: 199806

llvm-svn: 199805

llvm-svn: 199804

llvm-svn: 199803

implement correct atomic load/store for ARM
add test for atomic load/store
http://llvm-reviews.chandlerc.com/D2582

llvm-svn: 199802

llvm-svn: 199801

llvm-svn: 199800

Each functions is exported as "dllexport" in include/clang-c.
See also KB835326.

llvm-svn: 199799

because vector compare instruction puts result in mask register.

llvm-svn: 199798

MachineCopyPropagation has special logic for removing COPY instructions. It will remove plain COPYs using eraseFromParent(), but if the COPY has imp-defs/imp-uses it will convert it to a KILL, to keep the imp-def around.

This actually totally breaks and causes the machine verifier to cry in several cases, one of which being:

%RAX<def> = COPY %RCX<kill>
%ECX<def> = COPY %EAX<kill>, %RAX<imp-use,kill>

These subregister copies are together identified as noops, so are both removed. However, the second one as it has an imp-use gets converted into a kill:

%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>

As the original COPY has been removed, the verifier goes into tears at the use of undefined EAX and RAX.

There are several hacky solutions to this hacky problem (which is all to do with imp-use/def weirdnesses), but the least hacky I've come up with is to *always* remove COPYs by converting to KILLs. KILLs are no-ops to the code generator so the generated code doesn't change (which is why they were partially used in the first place), but using them also keeps the def/use and imp-def/imp-use chains alive:

%RAX<def> = KILL %RCX<kill>
%ECX<def> = KILL %EAX<kill>, %RAX<imp-use,kill>

The patch passes all test cases including the ones that check the removal of MOVs in this circumstance, along with an extra test I added to check subregister behaviour (which made the machine verifier fall over before my patch).

The patch also adds some DEBUG() statements because the file hadn't got any.

llvm-svn: 199797

Before:
  optional really.really.long.and.qualified.type.aaaaaaa
      .aaaaaaaa another_fiiiiiiiiiiiiiiiiiiiiield = 2;

After:
  optional
     really.really.long.and.qualified.type.aaaaaaa.aaaaaaaa
          another_fiiiiiiiiiiiiiiiiiiiiield = 2;

llvm-svn: 199796

It's guaranteed to be a CXXMethodDecl.

llvm-svn: 199795

Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.

Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.

Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.

llvm-svn: 199794

This helped catch a couple of bugs locally.

llvm-svn: 199793

llvm-svn: 199791

This involved making CheckReturnStackAddr into a static function, which
is now called by a top-level return value checking routine called
CheckReturnValExpr.

llvm-svn: 199790

llvm-svn: 199788

We don't currently support this option, but we should be able to parse it.

llvm-svn: 199787

llvm-svn: 199786

llvm-svn: 199785

llvm-svn: 199784

llvm-svn: 199783

the program, in C++. (We allow the latter as an extension, since we've always
permitted it, and GCC does the same, and our supported C++ ABIs don't do
anything special in main.)

llvm-svn: 199782

llvm-svn: 199781

when the deployment target is 10.5. // rdar://15852259

llvm-svn: 199780

AST consumers can determine where the destructor name was written. Patch by
Olivier Goffart!

llvm-svn: 199779